UCS stürzt ab, keine Anmeldung möglich, bootet nicht

UCS - Univention Corporate Server
#1

Hallo zusammen,

wir haben die aktuelle Core Edition installiert und nutzen Kolab.
UCS ist auf einer virtuellen Maschine mit 5,4GB Arbeitsspeicher und 2 Prozessoren installiert.
Ca. 1 mal in der Woche bleibt der Server stehen, die Anmeldung schlägt mit der Meldung einer beschädigten Datenbank fehl.
Nach dem Ausschalten der virtuellen Maschine bleibt diese beim Booten in der Meldung “Loading Files” stehen.
Die einzige Möglichkeit ist das Einspielen des aktuellen Backups - dadurch stehen aber leider keine Logs zur Verfügung.

Hatte jemand schon diesen Effekt oder eine Idee, wo die Ursache liegen könnte?

Vielen Dank

#2

Wir haben das gleiche Problem, seitdem wir von 4.1-0 auf 4.1-1 gegangen sind.
System bleibt einfach komplett ohne Anhaltspunkte stehen und muss hart resettet werden.
Seit neustem kann man sich auch nicht mehr an der Webconsole anmelden, man bekommt nach der Eingabe eine Nachricht die jedoch im Hintergrund nicht lesbar ist.
Gibt es dafür eine Lösung???
Die Management Web Console habe ich schonmal manuell neugestartet, aber die Meldung bleibt bestehen, dumm nur das man diese nicht lesen kann.

#3

[quote=“pt_it”]Wir haben das gleiche Problem, seitdem wir von 4.1-0 auf 4.1-1 gegangen sind.
System bleibt einfach komplett ohne Anhaltspunkte stehen und muss hart resettet werden.
Seit neustem kann man sich auch nicht mehr an der Webconsole anmelden, man bekommt nach der Eingabe eine Nachricht die jedoch im Hintergrund nicht lesbar ist.
Gibt es dafür eine Lösung???
Die Management Web Console habe ich schonmal manuell neugestartet, aber die Meldung bleibt bestehen, dumm nur das man diese nicht lesen kann.[/quote]

Für das Zweite Problem mit der Management Console solltest du dir folgenden Thread durchlesen:

#4

Ja danke, habe ich auch gerade danach gesehen.
Also das 2. Problem ist behoben, bleibt das kritischere Problem weiterhin.
Gestern Abend ist die virtuelle Maschine einfach stehen geblieben.
Davor war es am Freitag gegen nachmittag passiert, also relativ wahllos.

#5

Schau mal in die Logs vom UCS, steht da was brauchbares?

#6

Hab ich schon getan, kamen relativ viele Meldungen von rsyslogd rein, die jedoch aufgrund der Häufigkeit zusammengeführt worden sind, sodass man deren ursprüngliche Meldung nicht mehr nachvollziehen kann.
Diese Einstellung ist eine Standard-Einstellung in UCS, habe diese nun abgeändert, sodass ich jede Meldung im Syslog sehen, auch wenn diese über 500 mal nacheinander ankommt.
Mal sehen was passiert …

#7

Derzeit agieren wir derart, dass wir den Server ca. 1 Mal wöchentlich durchstarten, um dem Absturz zuvorzukommen.

#8

Hallo,

für die, die das Problem noch nicht genauso gesehen haben, sind die Fehlerbeschreibungen vermutlich unzureichend.
Mit “schlägt mit der Meldung einer beschädigten Datenbank fehl” kann ich zum Beispiel garnichts anfangen.
“Loading Files” habe ich so auch nicht sofort auf dem Schirm, beim Booten kommt eigentlich “Loading, please wait …”, aber es kann natürlich sein, dass Sie von einer ganz anderen Meldung reden.
Ich hätte vor dem Einspielen eines Backups wahrscheinlich versucht, mit einem externen Bootmedium an die Logs heranzukommen.

Die verwendete Virtualisierungsplattform und die Einstellungen der UCS-VM, insbesondere die Konfiguration der Platten könnten auch von Belang sein.

Viele Grüße,
Dirk Ahrnke

#9

Hallo,

leider muss ich nun auch von einem vergleichbaren (demselben?) Problem berichten.
In der Nacht auf heute, gegen 4:30 Uhr, ging laut ESXi die CPU-Last von allen zugewiesenen vCPUs (4 dediziert mit Reservierung für UCS) auf nahe 100%.
Anmeldeversuche mittels SCP oder Weboberfläche scheiterten. Direkt auf der Konsole sah man noch den Anmeldescreen des UCS/KDE mit der stehengebliebenen Uhrzeit.
Es half nur ein Hardreset.
Ich erwartete mir nun des Rätsels Lösung in im Kernel- oder Syslog. Der Syslog enthält aber keine besonderen Auffälligkeiten, und der Kernel-Log ist vom 29.02., 18:55 Uhr bis zum heutigen Neustart unterbrochen.

Da scheint was im Busch zu sein, aber mein Diagnose-Know-How ist dafür nicht groß genug…

Beste Grüße,
TP

#10

Hallo,

im syslog sollte man zumindest sehen, ob irgendwelche cron-jobs gestartet wurden.
Bei mir steht für 04:30 Uhr /usr/share/univention-ldap/create-dh-parameter-files an.
Ich würde nicht ausschließen, dass der openssl-Ruf erhebliche Last erzeugen kann, ob ob das für einen Crash im ESX reicht, kann ich nicht prüfen.

Viele Grüße,
Dirk Ahrnke

#11

Hallo,

einen named-Fehler gibt es, der wiederholt sich allerdings schon seit einigen Monaten. Ist nie aufgefallen. Wäre sicherlich mal in Ordnung zu bringen. Ansonsten laut mir nichts Spezielles:

Mar 3 04:25:02 ucs /USR/SBIN/CRON[13407]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13747]: (root) CMD ( [ -x /usr/lib/univention-pam/ldap-group-to-file.py ] && /usr/lib/univention-pam/ldap-group-to-file.py --check_member) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13779]: (root) CMD ([ -x /usr/sbin/univention-system-stats ] && /usr/sbin/univention-system-stats >/dev/null) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13786]: (root) CMD (/usr/share/univention-ldap/create-dh-parameter-files) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13792]: (root) CMD ( if [ -x /usr/sbin/univention-umount-homedirs ]; then /usr/sbin/univention-umount-homedirs; fi) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13821]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Mar 3 04:30:02 ucs /USR/SBIN/CRON[13832]: (root) CMD (/usr/sbin/univention-mrtg) Mar 3 04:30:03 ucs /USR/SBIN/CRON[13863]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1) Mar 3 04:33:33 ucs named[4350]: samba_dlz: starting transaction on zone domain.local Mar 3 04:33:33 ucs named[4350]: client 192.168.xxx.xxx#62668: update 'domain.local/IN' denied Mar 3 04:33:33 ucs named[4350]: samba_dlz: cancelling transaction on zone domain.local Mar 3 04:33:33 ucs named[4350]: samba_dlz: starting transaction on zone domain.local Mar 3 04:33:33 ucs named[4350]: samba_dlz: disallowing update of signer=SomeServer\$\@domain.local name=SomeServer.domain.local type=AAAA error=insufficient access rights Mar 3 04:33:33 ucs named[4350]: client 192.168.xxx.xxx#60631: updating zone 'domain.local/NONE': update failed: rejected by secure update (REFUSED) Mar 3 04:33:33 ucs named[4350]: samba_dlz: cancelling transaction on zone domain.local Mar 3 04:35:01 ucs /USR/SBIN/CRON[14081]: (root) CMD (/usr/sbin/jitter 60 /usr/share/univention-samba4/scripts/sysvol-sync.sh >>/var/log/univention/sysvol-sync.log 2>&1) Mar 3 04:35:01 ucs /USR/SBIN/CRON[14084]: (root) CMD (if [ -x /usr/bin/mrtg ] && [ -r /etc/mrtg.cfg ] && [ -d "$(grep '^[[:space:]]*[^#]*[[:space:]]*WorkDir' /etc/mrtg.cfg | awk '{ print $NF }')" ]; then mkdir -p /var/log/mrtg ; env LANG=C /usr/bin/mrtg /etc/mrtg.cfg 2>&1 | tee -a /var/log/mrtg/mrtg.log ; fi) Mar 3 13:21:10 ucs kernel: imklog 5.8.11, log source = /proc/kmsg started.

#12

Hallo,

der LDAP-cronjob scheints schonmal nicht zu sein.
Es gibt noch die Systemstatistiken, die kann man auch öfter erstellen lassen.

[code]# ucr search system/stats
system/stats/cron: 0,30 * * * *
Defines the interval for collecting system statistics. The configuration is done in Cron syntax, see ‘man 5 crontab’.

system/stats: yes
If this option is enabled, system properties such as the active processes, free disk space/system memory, the uptime and active Samba connections are logged regularly in the file /var/log/univention/system-stats.log.

[/code]

Viele Grüße,
Dirk Ahrnke

#13

Hallo Herr Ahrnke,

diese Stats unter /var/log/univention/system-stats.log hatte ich mir schon angeschaut!
Tatsächlich hatte ich einen, der unmittelbar davor gedumpt wurde. Allerdings ohne irgendwelche Auffälligkeiten im Load.

Sehr sonderbar, das Ganze.

Auch das Erzeugen und Konsolidieren eines Snapshots der VM hatte ich nochmals probiert, um herauszufinden, ob dies problematisch sein könnte. Ohne Auffälligkeiten.

Jedenfalls ist die Sache mal unter Beobachtung!

Danke für die immer wieder kompetente Hilfe!

VG,
TP

#14

Hallo,

hierzu kam noch ein Hinweis, den ich komplett zitiere:

[quote]Wenn das System ein UCS 4.0 oder UCS 4.1 ist, könnte man prüfen, ob es am
Kernel liegt:
(für amd64):
ucr set repository/online/component/3.2-8-errata=true
repository/online/component/3.2-8-errata/version=3.2
univention-install linux-image-3.10.0-ucs175-amd64
Und dann entsprechend den Kernel booten.[/quote]

Viele Grüße,
Dirk Ahrnke

#15

Hallo,

seitdem gab es KEINEN Freeze mehr. Ich warte auf jeden Fall ab, ggf. probiere ich den älteren Kernel!

Danke und viele Grüße,
TP

Mastodon