[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 30 Minuten Verzoegerung bei Reboot?



On Sat, 16 Jun 2018 23:56:42 +0200, Marc Haber
<mh+debian-user-german@zugschlus.de> wrote:
>ich habe eine kleine APU, auf der ein paar noch kleinere virtuelle
>Maschinen laufen. Alle beteiligten Betriebssysteme sind Debian stable
>mit einem eigenen, aktuellen Kernel.
>
>Wenn die Maschine ein paar Tage gelaufen ist und ich dann versuche,
>sie mit shutdown -r  now zu rebooten, läuft sie bis zu "Reached target
>Shutdown" herunter und bleibt an dieser Stelle stehen. Nach ziemlich
>genau 30 Minuten macht sie dann den Reset und bootet ganz normal.

Logeinträge:
|Aug  5 14:57:22 aida sudo:       mh : TTY=pts/0 ; PWD=/home/mh ; USER=root ; COMMAND=/sbin/shutdown -r now
|Aug  5 14:57:24 aida systemd[1]: session-909.scope: Killing process 20385 (ssh-agent) with signal SIGTERM.
|Aug  5 14:57:24 aida systemd[1]: Stopping Session 909 of user mh.
|Aug  5 14:57:24 aida systemd[1]: Unmounting /boot...
|Aug  5 14:57:24 aida systemd[1]: Unmounting /home...
|Aug  5 14:57:24 aida systemd[1]: session-3.scope: Killing process 1738 (ssh-agent) with signal SIGTERM.
|Aug  5 14:57:24 aida systemd[1]: Stopping Session 3 of user mh.
|Aug  5 14:57:24 aida systemd[1]: Stopping Session 910 of user mh.
|Aug  5 15:28:12 aida systemd[1]: Started LVM2 metadata daemon.
|Aug  5 15:28:12 aida systemd[1]: Starting Apply Kernel Variables...
|Aug  5 15:28:12 aida systemd[1]: Mounting Configuration File System...

Da steht nichts davon, dass irgend welche Dienste gestoppt werden.
Hier zum Vergleich ein Log von einer Maschine ohne Reboothemmung:
|Aug  5 15:59:35 prom sudo:       mh : TTY=pts/2 ; PWD=/home/mh ; USER=root ; COMMAND=/sbin/shutdown -r now
|Aug  5 15:59:37 prom systemd[1]: Stopping User Manager for UID 1001...
|Aug  5 15:59:37 prom systemd[1]: Unmounting /boot...
|Aug  5 15:59:37 prom systemd[1787]: Stopped target Default.
|Aug  5 15:59:37 prom systemd[1]: Stopped target Graphical Interface.
|Aug  5 15:59:37 prom systemd[1787]: Stopped target Basic System.
|Aug  5 15:59:37 prom systemd[1787]: Stopped target Paths.
|Aug  5 15:59:37 prom systemd[1787]: Stopped target Timers.
|Aug  5 15:59:37 prom systemd[1787]: Stopped target Sockets.
|Aug  5 15:59:37 prom systemd[1787]: Closed GnuPG cryptographic agent and passphrase cache.
|Aug  5 15:59:37 prom systemd[1787]: Closed GnuPG cryptographic agent (access for web browsers).
|Aug  5 15:59:37 prom systemd[1787]: Closed GnuPG cryptographic agent (ssh-agent emulation).
|Aug  5 16:00:42 prom systemd[1]: Started LVM2 metadata daemon.
|Aug  5 16:00:42 prom systemd[1]: Starting Create Static Device Nodes in /dev...
|Aug  5 16:00:42 prom systemd[1]: Starting udev Coldplug all Devices...

auch hier hätte ich mir eine etwas ausführliche Protokollierung des
Shutdown-Prozesses erhofft.

>In dieser Zeit laufen die virtuellen Maschinen ganz normal weiter,
>während, sie auf einer gleichartigen, nahezu identisch konfigurierten
>Maschine weit vor dem Erreichen von "Reached target Shutdown"
>ordentlich heruntergefahren werden. Es gibt da auch keinen Prozess,
>der auf das Herunterfahren der VMs wartet; wenn ich die ordentlich mit
>shutdown -h now stoppe, wartet der Host dennoch bis die 30 Minuten
>voll sind. Die Maschine selbst ist in diesem Zustand anpingbar;
>ssh-Sessions werden vorher sauber beendet, Konsolen-Logins werden
>ausgelogged, ein neuer Login ist hüben wie drüben nicht möglich.

Dieses Verhalten schließt, finde ich, irgend welche ACPI/BIOS-Issues
beim Reboot und auch Watchdog-Probleme aus, denn das System scheint ja
ordentlich zu laufen, und ich würde von ihm erwarten, dass es die VMs
ordentlich runterfährt bevor es sich an den Versuch des
Hardware-Neustarts macht. Mein Bauchgefühl sagt, dass ich den Fehler
irgendwo in den Tiefen von systemd suchen muss.

Kann man:
- den Loglevel hochdrehen?
- systemd dazu bringen, genauer zu sagen was es wann in welcher
  Reihenfolge beim Shutdown macht und warum?
- verhindern, dass Systemd als erste Amtshandlung alle interaktiven
  User inklusive mir rauswirft und einen weiteren Login verhindert?
- irgendwie sowas wie eine Debug-Shell beim _herunterfahren_ bekommen?

Insbesondere würde mich brennend interessieren, was libvirt/virsh zu
den VMs sagt, wenn ich innerhalb der VM noch ein "shutdown -h now"
eingetippt habe.

Grüße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


Reply to: