Wie kann ich herausfinden, welcher Dienst systemd während des Herunterfahrens blockiert, wenn ich kein Protokoll abrufen kann?
Ich versuche schon seit Tagen herauszufinden, warum systemd hängen bleibt, wenn ich versuche, neu zu starten oder herunterzufahren. Der Herunterfahrvorgang wird teilweise durchgeführt, aber nie abgeschlossen. Dieses System befindet sich auf einer Maschine, auf die nur eine serielle Konsole für den Zugriff zur Verfügung steht. Es gibt keine Ethernet-Ports. Die einzige beschreibbare Festplatte ist ein RAM-Laufwerk, daher ist es sinnlos, nach dem Neustart auf journalctl zu schauen.
Die Architektur ist Ubuntu 18.04 auf einem Arm64 und alles, was ich weiß, ist Folgendes:
[ OK Stopping Session 3 of user root.
[ OK ] Stopped target Timers.
[ OK ] Stopped Daily apt upgrade and clean activities.
[ OK ] Stopped Daily apt download activities.
[ OK ] Stopped Daily Cleanup of Temporary Directories.
Stopping Authorization Manager...
[ OK ] Stopped Discard unused blocks once a week.
Stopping Availability of block devices...
[ OK ] Stopped target Graphical Interface.
Stopping Disk Manager...
[ OK ] Stopped target Multi-User System.
Stopping strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf...
Stopping System Logging Service...
[ OK ] Stopped target Login Prompts.
Stopping Getty on tty1...
Stopping Serial Getty on ttyS0...
Stopping Unattended Upgrades Shutdown...
Stopping Dispatcher daemon for systemd-networkd...
Stopping D-Bus System Message Bus...
Stopping Chassis Fan Service...
Stopping Regular background program processing daemon...
Stopping OpenBSD Secure Shell server...
[ OK ] Stopped Resets System Activity Data Collector.
Stopping vsftpd FTP server...
Stopping Nexcopy Graphical Interface...
[ OK ] Stopped Nexcopy Gadget Service.
Stopping LSB: Load kernel image with kexec...
Stopping LSB: HPA's tftp server...
Stopping User Manager for UID 0...
[ OK ] Stopped target Host and Network Name Lookups.
Stopping Getty on ttyGS0...
[ OK ] Stopped Message of the Day.
Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
[ OK ] Stopped System Logging Service.
[ OK ] Stopped Dispatcher daemon for systemd-networkd.
[ OK ] Stopped Disk Manager.
[ OK ] Stopped strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf.
[ OK ] Stopped Regular background program processing daemon.
[ OK ] Stopped vsftpd FTP server.
[ OK ] Stopped Unattended Upgrades Shutdown.
[ OK ] Stopped Serial Getty on ttyS0.
[ OK ] Stopped Nexcopy Graphical Interface.
[ OK ] Stopped Getty on tty1.
Was auch immer das Hängen verursacht, ist wahrscheinlich der nächste Dienst, der versucht wird, zu starten. Wie kann ich feststellen, was das ist?
„reboot -f“ funktioniert einwandfrei, daher weiß ich, dass es sich nicht um ein Hardwareproblem handelt.
Gibt es eine Möglichkeit, systemd dazu zu bringen, ausführlichere Informationen über den Dienst auszugeben, den es zu stoppen versucht?
Ich habe es versucht:
systemctl reboot --dry-run
Ich hoffte, es könnte mir sagen, was es versucht hat, aber anscheinend wird --dry-run ignoriert, weil es trotzdem einen echten Herunterfahrvorgang eingeleitet hat.
Gibt es eine Möglichkeit, systemd dazu zu bringen, seine Aufgabenliste auszugeben, damit ich sehen kann, was als nächstes in der Warteschlange steht? Da ich nur über eine einzige serielle Konsole darauf zugreifen kann, weiß ich nicht, was ich sonst noch versuchen kann.
Hat jemand einen Vorschlag?
Bearbeiten: Eine Frage habe ich, nachdem ich mir das noch einmal angesehen habe. ttyS0 in diesem System ist die Konsole und der Port, an dem ich angemeldet bin. Kurz bevor die Nachrichten beendet werden, stelle ich fest, dass Getty an diesem Port angehalten wird und ich daher vermutlich abgemeldet bin. Könnte das Anhalten von Getty verhindern, dass weitere Daten gemeldet werden? Und wenn ja, gibt es eine Möglichkeit, dies zu umgehen?