Nach Proxmox-Hänger startet linuxmuster 6.2 nicht mehr

Hallo,

heute morgen ist unser Proxmox offenbar bei dem Versuch abgeschmiert, ein Backup der linuxmuster-vm (6.2) auf einem NAS zu erstellen, auf dem nicht mehr ausreichend Platz vorhanden war. Normalerweise bricht das Backup dann ab, diesmal aber waren die VMs nicht mehr zu erreichen (was vor allem wegen dem fehlenden ldap ein Problem wurde, weil bei Moodle und Nextcloud nichts mehr ging…).

Auch die Weboberfläche von Proxmox war nicht mehr zu erreichen, auf der Konsole am Rechner konnte ich mich aber noch einloggen und den shutdown einleiten. Den habe ich dann aber nach 20 Minuten mit der Aus-Taste am Server hart beendet, weil es nicht mehr voran ging (7 Prozesse warteten ohne timeout auf Beendigung).

Proxmox fuhr danach wieder problemlos hoch, die Firewall und eine weitere VM starteten ebenfalls problemlos, nur der linuxmuster-server blieb bei „Starting System V initialisation compatibility“ hängen. Manchmal auch bei „Starting configure network device“.

Das syslog meldete Dateisystem-Fehler (die sich beheben ließen), die Swap-Partition ließ sich offenbar nicht schnell genug einbinden (ließ sich nicht beheben) und er bemängelte das fehlende Verzeichnis /run/rpcbind. Außerdem bemängelte ntpdate einen „failure in name resolution“.

Nach ein paar Stunden erfolgloser Fehlersuche habe ich das Backup von voriger Woche eingespielt. Aber das startete auch nicht, zwar keine Dateisystemfehler, die Swap-Partition arbeitet offenbar auch ohne Probleme, aber der Serverboot bleibt bei „Mount network filesystems“ stehen.

Wenn ich dann nach einiger Zeit (> 15 min) den Bootvorgang mit Strg-Alt-Entf abbreche und im recovery mode starte, steht im boot.log nach „Starting emergency keypress handling“ noch „error: ‚quota‘ exited outside the expected code flow.“ Im Flow war ich da schon lange nicht mehr.

Der recovery-mode von ubuntu hat mir dann aber doch noch weitergeholfen: Ich konnte auf der root-Konsole nämlich die Partitionen mounten, das Netzwerk aktivieren und den slapd starten. Sogar ssh tut. Damit läuft Moodle Gott sei Dank wieder, das wird bei uns nämlich kräftig genutzt, habe extra einen eigenen DB-Server drangehängt, damit flutscht die Sache so richtig!

Aber in der Schule geht weiter nix mehr, und das würde ich (auch wenn das Schulhaus natürlich ziemlich leer ist - bis auf den Elektriker, der die Zeit nutzt und neue APs verkabelt!) gerne ändern.

Hat jemand einen Tipp, an was der mangelnde Start hängen könnte? Wie gesagt, die logs geben dazu leider nichts her.

Grüße,
Stefan

Hallo Stefan,

Vielleicht alle unnötige mounts in /etc/fstab erst mal auskommentieren ?
Problem mit rpcbind sind oft mit NFS-Mount-Problem gebunden.

Gruß

Arnaud

Hallo Arnaud,

da stehen nur root, home, var und swap drin, sonst nix.

Grüße,
Stefan

Hallo Stefan,

keine Ahnung, daher völlig in’s Blaue hinein:
Plattenplatz?
Inodes? df -i

LG,
Jochen

Hallo Jochen,

beides noch ausreichend vorhanden.

Grüße,
Stefan

Hallo Stefan,

vielleicht hilft dir diese Information es ja:
ich habe letzte Woche meinen KVM Host in der Schule upgedatet.
Dabei hab ich den Kernel gewechselt: von 4.15 auf 5.3 (glaub ich): war
auf jeden Fall ein größerer Schitt (HWE von ubuntu 18.04).
Danach starteten zwei meiner virtuellen server nicht mehr.
Die anderen 4 (oder so) starteten aber ohne Probleme.
Natürlich war der Hauptserver unter denen, die nicht gestartet haben…
Ich habe dann rausgefunden, dass es an der Einstellung der virtuellen
Maschine in KVM lag.
Die beiden betroffenen server hatten bei der CPU nichts spezielles
eingetragen, bei den anderen stand drin, dass es ein EPYC Prozessor ist.
Ich meine, das ist das, was der virtuelaisierer dem HOst sagt, um welche
CPU es sich handelt.
Mit 4.15 ging es noch so, mit 5.3 nicht mehr.
Seit ich das umgestellt habe, geht alles wieder.

Die betroffenen server fuhren auch nicht richtig hoch und blieben an
unterschiedlichen Stellen hängen.

Vielelciht kannst du auch was an den CPU Einstellungen für die VMs
machen …

Viele Grüße

Holger

Hallo Holger,

hm, keine Unterschiede außer bei der Anzahl der Prozessoren (für Linuxmuster je 2 Kerne auf 2 Sockeln für die anderen nur einen Kern) und beim Display (VMware compatible, bei den anderen Default). Aber letzteres hat schon häufiger rumgezickt, hab ich nur schon wieder verdrängt. Werde ich ausprobieren, geht nur nicht von zu Hause…

Viele Grüße,
Stefan

Hallo Holger,

wäre ja schön gewesen… Hat aber leider nichts geholfen.

Interessant ist, dass es mit unterschiedlichen Display-Einstellungen jeweils an anderer Stelle hing (ich habe aus Zeitgründen - ich wollte die Downtime nicht zu sehr in die Länge ziehen - das nicht mehrmals mit den gleichen Einstellungen verifiziert), einmal auch zwei Schrite weiter als sonst immer (bis „Stopping set sysctls from /etc/sysctl.conf“).

Grüße,
Stefan

Hallo Stefan,

spiel doch mal dein Backup in eine neue Maschine zurück und häng die
externe Schnittstelle an eine andere Netzwerkkarte: dann kannst du die
gleichzeitig starten und so ohne Beeinträchtigungen reparieren.

LG

Holger

Hallo Holger,

bin jetzt dazu gekommen, das Backup auf meinen Ersatzserver zu spielen, hab dann gestartet und lange gewartet (bisher habe ich meine Versuche immer nach spätestens 20 Minuten Stillstand abgebrochen). Und siehe da: Er machte beim booten nur eine äußerst lange Denkpause, wie man an der syslog sieht:

Apr 2 13:34:52 centaurus avahi-daemonahi-daemon[9761: Registering HINFO record with ualues ‚X86_64VLINUX‘ .
Apr 2 13:34:53 centaurus avahi-daemon[976]: Server startup complete. Host name is centaurus.local. Local service cookie is 3279038.
Apr 2 13:34:57 centaurus ntpdate[1062]: name server cannot be used: Temporary failure in name resolution (-3)
Apr 2 13:34:57 centaurus ntpd[1088]: listening on 10.32.1.1
Apr 2 13:34:57 centaurus ntpd[1088]: ntp engine ready
Apr 2 13:35:07 centaurus ntpd[1088]: ntp engine exiting
Apr 2 13:35:07 centaurus ntpd[1087]: Terminating
Apr 2 13:35:07 centaurus ntpdate[1204]: name server cannot be used: Temporary failure in name resolution (-3)
Apr 2 13:35:07 centaurus ntpd[1230]: listening on 10.32.1.1
Apr 2 13:35:07 centaurus ntpd[1230]: ntp engine ready
Apr 2 13:35:08 centaurus kernel: [ 46.152318] init: failsafe main process (924) killed by TERM signal
Apr 2 13:45:08 centaurus ntpd[1230]: 0 out of 4 peers valid
Apr 2 13:45:08 centaurus ntpd[1230]: bad peer 0.debian.poo1.ntp.org (not resolved)
Apr 2 13:45:08 centaurus ntpd[1230]: bad peer 1.debian.poo1.ntp.org (not resolved)
Apr 2 13:45:08 centaurus ntpd[1230]: bad peer 2.debian.poo1.ntp.org (not resolved)
Apr 2 13:45:08 centaurus ntpd[1230]: bad peer 3.debian.poo1.ntp.org (not resolved)
Apr 2 14:16:55 centaurus kernel: [ 2552.9252651 audit_printk_skb: 24 callbacks suppressed
Apr 2 14:16:55 centaurus kernel: [ 2552.9252721 type=1400 audit(1585829815.441:20): apparmor=„STATUS“ operation=„profi1e_rep1ace“ profi1e=„unconfined“ name=„/sbin/dhc1ient“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2552.9252861 type=1400 audit(1585829815.441:21): apparmor=„STATUS“ operation=„profile_replace“ profile=„unconfined“ name=„/usr/1ib/NetworkManager/nm-dhcp-c1ient.action“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2552.9252921 type=1400 audit(1585829815.441:22): apparmor=„STATUS“ operation=„profi1e_rep1ace“ profi1e=„unconfined“ name=„/usr/1ib/connman/scripts/dhc1ient-script“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2552.9264541 type=1400 audit(1585829815.441:23): apparmor=„STATUS“ operation=„profile_replace“ profile=„unconfined“ name=„/usr/1ib/NetworkManager/nm-dhcp-c1ient.action“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2552.9264641 type=1400 audit(1585829815.441:24): apparmor=„STATUS“ operation=„profile_replace“ profile=„unconfined“ name=„/usr/lib/connman/scripts/dhc1ient-script“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2552.9273621 type=1400 audit(1585829815.441:25): apparmor=„STATUS“ operation=„profi1e_rep1ace“ profi1e=„unconfined“ name=„/usr/1ib/connman/scripts/dhc1ient-script“ pid=1508 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2553.0923621 type=1400 audit(1585829815.609:26): apparmor=„STATUS“ operation=„profi1e_1oad“ profi1e=„unconfined“ name=„/usr/bin/freshc1am“ pid=1509 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2553.1301211 type=1400 audit(1585829815.645:27): apparmor=„STATUS“ operation=„profile_load“ profile=„unconfined“ name=„/usr/sbin/clamd“ pid=1510 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2553.1543451 type=1400 audit(1585829815.669:28): apparmor=„STATUS“ operation=„profi1e_1oad“ profi1e=„unconfined“ name=„/usr/1ib/cups/backend/cups-pdf“ pid=1511 comm=„apparmor_parser“
Apr 2 14:16:55 centaurus kernel: [ 2553.1543561 type=1400 audit(1585829815.669:29): apparmor=„STATUS“ operation=„profile_load“ profile=„unconfined“ name=„/usr/sbin/cupsd“ pid=1511 comm=„apparmor_parser“
Apr 2 14:16:57 centaurus acpid: starting up with netlink and the input layer
Apr 2 14:16:57 centaurus acpid: 1 rule loaded
Apr 2 14:16:57 centaurus acpid: waiting for events: event logging is off

In der boot.log kann ich nachvollziehen, dass es zwischen der Zeile:

Starting configure network device

und der Zeile

Checking quotas

gewesen sein muss. Was auch immer er da zu checken hatte.

Ich werde das am Produktivsystem ausprobieren, wenn wenig Last am ldap anliegt, also voraussichtlich am Wochenende…

Grüße,
Stefan

Hallo Stefan.

Genau an der Stelle dauert es hier auch lange – aber nicht soooo lange!
Schöne Grüße,
Michael

Hallo,

da ist wohl die Quotadatenbank beschädigt worden und er baut sie beim
booten komplett wieder auf: bei vielen Daten kann das dauern…

LG

Holger

Hi Holger.

das ist bei uns bei jedem Neustart so – auch, wenn ich ganz regulär per reboot neu starte. Ob da wirklich was defekt ist? :thinking:
Schönen Gruß,
Michael

Hallo,

ich habe auf meinem Uralt-Testserver linuxmuster zum zweiten Mal starten lassen, diesmal ist er in 4 Minuten (die VM hat nur einen Core und 3GB RAM) gestartet, könnte also wirklich der Quota-Check gewesen sein.

Grüße,
Stefan

Hallo Stefan,

Das machen meine Server von Zeit zu Zeit auch mal. Das ist nichts ungewöhnliches. Nur wenn man remote gestartet hat, dann kommt man ins Schwitzen.

Gruß

Alois