systemd / ssh / reboot: Sitzung hängt

[heisenberg]

Hallo zusammen,

eine Problem das seit systemd mit Debian Jessie bzw. Ubuntu Xenial Einzug gehalten hat, ist das sich beim per SSH ausgelösten Neustart / Shutdown die SSH-Sitzung aufhängt. Das hat wohl damit zu tun, dass systemd so schnell wie möglich versucht alle Prozesse zu beenden, so dass das Netzwerk schon weg ist, bevor die SSH-Sitzung getrennt werden kann.

Als Lösung, die scheinbar funktioniert wird empfohlen die Pakete libpam-systemd und dbus zu installieren und desweiteren in sshd_config die Option UsePAM yes zu setzen.

Gibt es da noch andere Alternativen?

Grüße,
h.

P. S.: Habe gerade die zugehörigen Bugreports gefunden:

• https://bugs.debian.org/cgi-bin/bugrepo ... bug=751636
• https://bugs.launchpad.net/ubuntu/+sour ... ug/1464917

[MSfree]

Diese Hänger kenne ich auch, ich hatte sie aber auch schon mit früheren Debianversionen.

Sobald der neu gestartete Rechner aber wieder am Netz hängt, und man dann die Entertaste in dem hängenden SSH-Client betätigt, beendet sich auch der Client sauber.

[heisenberg]

Sobald der neu gestartete Rechner aber wieder am Netz hängt, und man dann die Entertaste in dem hängenden SSH-Client betätigt, beendet sich auch der Client sauber.

Ja. Das hilft aber nicht, wenn man per Script rebootet. Da musste ich jetzt vor alle reboots ein timeout-Kommando setzen. Natürlih bekommt man so nicht mit, ob der reboot überhaupt geklappt hat oder nicht. Aber auch dafür kann man wieder einen Workaround basteln, was man aber eigentlich nicht haben will.

Im Debian-Bug-Report steht ganz unten, dass wohl mittlerweile(22.7.2016) in OpenSSH ein Fix dafür drin sein soll. Dann wird das hoffentlich bei Stretch gefixt sein.

[mat6937]

Das hat wohl damit zu tun, dass systemd so schnell wie möglich versucht alle Prozesse zu beenden, so dass das Netzwerk schon weg ist, bevor die SSH-Sitzung getrennt werden kann.

Das kann ich nicht bestätigen, denn auch bei einem "shutdown -r now" sendet auf meinen ssh-Servern (LAN/VPN und/oder Internet) mit systemd, der SSH-2.0-OpenSSH_6.7p1-Server (und das ohne "UsePAM yes") einen Hinweis mit dem reset-Flag an den ssh-Client, der beim ssh-Client auch ankommt:

Code: Alles auswählen

192.168.178.43.22 > 192.168.178.21.45897: Flags [R], cksum 0x0f9c (correct), seq 3408080681, win 0, length 0

Das kann man auf dem Client, mit z. B.:

Code: Alles auswählen

tcpdump -vvveni any port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'

sehen/sniffen.

BTW: Je nach Konfiguration des ssh-Clienten betr. "ServerAliveCountMax/ServerAliveInterval", beendet dieser die Verbindung zum ssh-Server ordnungsgemäß und gibt den prompt frei.

[TomL]

Das hat wohl damit zu tun, dass systemd so schnell wie möglich versucht alle Prozesse zu beenden, so dass das Netzwerk schon weg ist, bevor die SSH-Sitzung getrennt werden kann.

Nein,das glaube ich eher nicht. Systemd hält sich beim "reboot" strikt an die umgekehrt Reihenfolge beim Schließen der Dienste, wie sie beim Booten gestartet wurden - sofern man nichts anderes bestimmt hat. Der SSH-Server wird durch das Statement "After=network.target" erst nach dem das Netzwerk gestartet. Das kann man schön im Log nachsehen, ebenso wie die umgekehrte Reihenfolge beim Schließen. Die Eindeutigkeit, dass es beim Boot wirklich "danach" erfolgt ist, kann man entweder aus der Sekunden-Anzeige beim Poweroff ableiten, oder einfach mit systemd-analyze plot bestätigen.

Code: Alles auswählen

# journalctl -b -1 -u ssh
-- Logs begin at Fri 2017-02-17 13:51:44 CET, end at Mon 2017-02-20 14:31:07 CET. --
Feb 19 18:45:49 thomaspc systemd[1]: Starting OpenBSD Secure Shell server...
Feb 19 18:45:49 thomaspc sshd[1759]: Server listening on 0.0.0.0 port 22.
Feb 19 18:45:49 thomaspc sshd[1759]: Server listening on :: port 22.
Feb 19 18:45:49 thomaspc systemd[1]: Started OpenBSD Secure Shell server.
Feb 19 22:49:54 thomaspc systemd[1]: Stopping OpenBSD Secure Shell server...
Feb 19 22:49:54 thomaspc systemd[1]: Stopped OpenBSD Secure Shell server.

# journalctl -b -1 -u network.target
-- Logs begin at Fri 2017-02-17 13:51:44 CET, end at Mon 2017-02-20 14:31:07 CET. --
Feb 19 18:45:49 thomaspc systemd[1]: Reached target Network.
Feb 19 22:49:55 thomaspc systemd[1]: Stopped target Network.

Allerdings besteht hier der Umstand, dass nach "network.target" noch nicht zwingend eine IP via DHCP vergeben sein muss. Das Netzwerk wurde zwar erfolgreich gestartet, aber es ist noch damit beschäftigt, sich "ordentlich" zu verbinden. Das hat aber keinen Einfluss auf den Zeitpunkt beim Shutdown, dass das Interface seitens systemd ggf. vor dem SSH-Service geschlossen wird. Ich vermute, der Übeltäter wird ein bzw. der Networkmanager sein, denn der wird anscheinend über den geplanten Shutdown via dbus informiert und kloppt dann einfach alles an offenen Verbindungen weg. Wenn es sich hier bei dem Problem auch noch um eine WLAN-Verbindung handelt, bin ich sogar fast sicher, dass der NWM der Übeltäter ist.

[MSfree]

Nein,das glaube ich eher nicht. Systemd hält sich beim "reboot" strikt an die umgekehrt Reihenfolge beim Schließen der Dienste, wie sie beim Booten gestartet wurden

Im Prinzip ist das richtig.

Was ich bisher aber noch nicht analysiert habe ist, wie systemd den sshd beendet. Üblicherweise sollte sshd erstmal ein SIGHUP bekommen, um Gelegenheit zu bekommen, die Verbindungen zu schließen. Dann würden die Clients nämlich auch mitbekommen, wenn sshd sich beendet.

Wenn systemd den sshd mit kill -9 abwürgt, entsteht das beobachtete Phänomen.

[smutbert]

Darf ich einmal fragen um welche Netzwerkinterfaces es bei euch geht?

Bei mir treten die gestorbenen und blockierten ssh-Sitzungen nämlich nur bei der Verwendung des network-manager (am ssh-Server) auf und nicht wenn ich das Netzwerk in der /etc/network/interfaces konfiguriere.

[TomL]

Wenn systemd den sshd mit kill -9 abwürgt, entsteht das beobachtete Phänomen.

Das kann ich zum Teil beantworten. systemd sendet beim Stop eines Dienstes SIGTERM, also 15, damit der Prozess sich ordentlich beenden kann. Und wenn der Prozess darauf nicht reagiert, wird er getötet. Aber ich konnte nicht verifizieren, ob vorher noch SIGKILL, also 9, gesendet wird... SIGKILL konnte ich überhaupt nicht feststellen, ebensowenig wie SIGHUP.

Nachtrag:
Ich habe noch mal ein bischen rumgespielt und glaube nun, der Job wird einfach getötet, wenn er nicht freiwillig nach SIGTERM das Feld räumt. Ich habe mit etlichen Signalen rumprobiert und ich krieg sie alle im Job mit.... nur bei SIGKILL ist offensichtlich sofort fini.

[MSfree]

Das kann ich zum Teil beantworten. systemd sendet beim Stop eines Dienstes SIGTERM, also 15, damit der Prozess sich ordentlich beenden kann.

OK, SIGTERM kann man abfangen und theoretisch könnte sshd entsprechend reagieren. Ob es das tut, kann ich gerade nicht sagen.

Und wenn der Prozess darauf nicht reagiert, wird er getötet.

SIGKILL kann nicht abgefangen werden und der Prozeß wird, ohne daß der sich noch wehren kann, sofort getötet, offene Verbinidungen werden abrupt beendet, Clients bekommen nichts davon mit und warten dann auf ihr Timeout.

Aber ich konnte nicht verifizieren, ob vorher noch SIGKILL, also 9, gesendet wird.

Das will ich doch mal nicht hoffen.

ebensowenig wie SIGHUP.

SIGHUP wäre die freundlichere Methode im Vergleich zu SIGTERM, aber sshd sollte beide abfangen können und die Leitungen sauber schließen können.

[TomL]

SIGKILL kann nicht abgefangen werden und der Prozeß wird, ohne daß der sich noch wehren kann, sofort getötet

Ok, so fit bin ich nicht... ich hätte gedacht, der Job kriegt noch ne letzte Chance oder so ...*lacht*...Ja, SIGTERM ist bei "systemctl stop" absolut zuverlässig feststellbar. Und ich würde nicht davon ausgehen, dass das beim Shutdown anders abläuft.

[MSfree]

ich würde nicht davon ausgehen, dass das beim Shutdown anders abläuft.

Dazu habe ich jetzt mal einen einfachen Test durchgeführt:

1. auf einem Server läuft ein sshd
2. ich logge mich von einem Client auf dem Server ein
3. auf der Konsole des Servers führe ich systemctl stop ssh aus

Witizigerweise läuft die Verbindung auf dem Client weiter. Die Erklärung dafür ist recht trivial. Systemd startet einen Parent-sshd-Prozeß. Bei einem SSH-Login von aussen forkt der Parent-sshd einen Child-sshd-Prozeß. Der Befehl in Punkt 3 stoppt nun nur Parentprozeß, die Loginshell bleibt bestehen.

Bei einem Shutdown wird systemd wohl den Parent-sshd mit SIGTERM beenden, die Childprozesse leben aber weiter, wahrscheinlich sogar über den Zeitpunkt hinaus, wo die Netzwerkschnittstelle(n) abgehängt werden. Das Resultat ist, daß die remote Loginshell hängt.

Da die Child-Prozesse nicht von systemd verwaltet werden, geht systemd eben davon aus, daß alles in der rückwärtigen Reihenfolge gestoppt werden kann. Alles, was danach noch lebt (z.B. der Child-sshd), wird irgendwie gekillt. Aber zu dem Zeitpunkt ist es sowieso schon zu spät, der remote Login hängt bereits.

[mat6937]

Der Befehl in Punkt 3 stoppt nun nur Parentprozeß, die Loginshell bleibt bestehen.

Da die Child-Prozesse nicht von systemd verwaltet werden, geht systemd eben davon aus, daß alles in der rückwärtigen Reihenfolge gestoppt werden kann. Alles, was danach noch lebt (z.B. der Child-sshd), wird irgendwie gekillt. Aber zu dem Zeitpunkt ist es sowieso schon zu spät, der remote Login hängt bereits.

Auch wenn der sshd-Parentprozeß im Vorfeld mit systemctl gestoppt ist, geht bei einem (d. h. unmittelbar vor dem) shutdown, von dem Child-sshd (Source-Port 22 auf dem Server) noch eine (oder mehrere) Nachricht(en) (... den Abbruch der ssh-Verbindung betreffend) an den ssh-Client.

[MSfree]

unmittelbar vor dem) shutdown, von dem Child-sshd (Source-Port 22 auf dem Server) noch eine (oder mehrere) Nachricht(en) (... den Abbruch der ssh-Verbindung betreffend) an den ssh-Client.

Nein, denn die Netzwerkschnittstellen sind zu dem Zeitpunkt schon weg. Die Clients kannst du nur noch via Power-LED am Gehäuse anmorsen.

Die Reihenfolge beim Shutdown ist:

systemd stoppt den Parent-sshd
systemd bringt das Netzwerk runter
systemd killt alles, was jetzt noch lebt, unter anderem den Child-sshd

[mat6937]

unmittelbar vor dem) shutdown, von dem Child-sshd (Source-Port 22 auf dem Server) noch eine (oder mehrere) Nachricht(en) (... den Abbruch der ssh-Verbindung betreffend) an den ssh-Client.

Nein, denn die Netzwerkschnittstellen sind zu dem Zeitpunkt schon weg. ...

Die Netzwerkschnittstellen sind nicht weg. Wenn ich das so geschrieben habe, dann heißt das, dass ich das auch getestet habe. Kannst ja mal selber probieren.

[TomL]

Die Reihenfolge beim Shutdown ist:
systemd stoppt den Parent-sshd
systemd bringt das Netzwerk runter
systemd killt alles, was jetzt noch lebt, unter anderem den Child-sshd

Nee! Die Reihenfolge kann man im Log nachsehen:

Code: Alles auswählen

$ journalctl -b -1 -u network.target -u ssh
-- Logs begin at So 2017-02-19 14:13:13 CET, end at Mo 2017-02-20 19:46:52 CET. --
Feb 20 19:44:20 dell-e6320 systemd[1]: Starting Network.
Feb 20 19:44:20 dell-e6320 systemd[1]: Reached target Network.
Feb 20 19:44:20 dell-e6320 systemd[1]: Starting OpenBSD Secure Shell server...
Feb 20 19:44:20 dell-e6320 systemd[1]: Started OpenBSD Secure Shell server.
Feb 20 19:44:22 dell-e6320 sshd[1358]: Server listening on 0.0.0.0 port 22.
Feb 20 19:44:22 dell-e6320 sshd[1358]: Server listening on :: port 22.
Feb 20 19:44:51 dell-e6320 sshd[1801]: Accepted publickey for thomas from 10.10.1.41 port 22222 ssh2: RSA 12.22:33:44:55:aa:bb:cc:dd
Feb 20 19:44:51 dell-e6320 sshd[1801]: pam_unix(sshd:session): session opened for user thomas by (uid=0)
Feb 20 19:45:12 dell-e6320 systemd[1]: Stopping OpenBSD Secure Shell server...
Feb 20 19:45:12 dell-e6320 systemd[1]: Stopped OpenBSD Secure Shell server.
Feb 20 19:45:15 dell-e6320 systemd[1]: Stopping Network.
Feb 20 19:45:15 dell-e6320 systemd[1]: Stopped target Network.

$ journalctl -b -1 | grep sshd
Feb 20 19:44:22 dell-e6320 sshd[1358]: Server listening on 0.0.0.0 port 22.
Feb 20 19:44:22 dell-e6320 sshd[1358]: Server listening on :: port 22.
Feb 20 19:44:51 dell-e6320 sshd[1801]: Accepted publickey for thomas from 10.10.1.41 port 22222 ssh2: RSA 12.22:33:44:55:aa:bb:cc:dd
Feb 20 19:44:51 dell-e6320 sshd[1801]: pam_unix(sshd:session): session opened for user thomas by (uid=0)
Feb 20 19:45:12 dell-e6320 sshd[1801]: pam_unix(sshd:session): session closed for user thomas
Feb 20 19:45:12 dell-e6320 sshd[1358]: Received signal 15; terminating.
Feb 20 19:45:12 dell-e6320 sshd[1801]: pam_systemd(sshd:session): Failed to release session: Connection reset by peer

Wobei ich unsicher bin, ob das auch gilt, wenn der Networkmanager seine Finger im Spiel hat und es um WLAN geht. Ich glaube, dann wird das Ergebnis ein anderes sein. BTW, die Zeiten liegen hier alle dicht bei einander, weil ich kurz den Laptop gestartet habe, sofort ssh verbunden habe und dann direkt "reboot" abgeschickt habe.

[MSfree]

Nee! Die Reihenfolge kann man im Log nachsehen:

Code: Alles auswählen

$ journalctl -b -1 -u network.target -u ssh
...
Feb 20 19:45:12 dell-e6320 sshd[1801]: pam_systemd(sshd:session): Failed to release session: Connection reset by peer

Doch, denn der sshd Prozeß mit der PID 1801 kann nicht gestoppt werden, weil da das Netz schon weg ist.

Wobei ich unsicher bin, ob das auch gilt, wenn der Networkmanager seine Finger im Spiel hat

Meinen Test habe ich ohne Networkmanager durchgeführt, Netzwerk also ganz oldschool via /etc/network/interfaces.

[heisenberg]

Bei einem Shutdown wird systemd wohl den Parent-sshd mit SIGTERM beenden, die Childprozesse leben aber weiter, wahrscheinlich sogar über den Zeitpunkt hinaus, wo die Netzwerkschnittstelle(n) abgehängt werden. Das Resultat ist, daß die remote Loginshell hängt.

Das erinnert mich an zwei Dinge, weiss jetzt nicht ob das etwas mit diesem Phänomen zu tun hat:

1. Ist es nicht eine spezielle Fähigkeit von systemd, das es neu erzeugte Kindprozesse verfolgen kann(cgroups) und deswegen grundsätzlich auch beenden kann(wenn es denn so vorgesehen ist)?
2. systemd killt Hintergrundprozesse von normalen, lokalen login-Sitzungen, wenn man das nicht speziell aktiviert.

[MSfree]

Ist es nicht eine spezielle Fähigkeit von systemd, das es neu erzeugte Kindprozesse verfolgen kann(cgroups) und deswegen grundsätzlich auch beenden kann(wenn es denn so vorgesehen ist)?

Das Problem ist bei SSH aber, daß das Beenden von Childprozessen zu unerwünschten Nebeneffekten führen kann. Stell dir vor, ein Admin loggt sich per SSH auf einem Server ein, der irgendwo in Weitwegistan in einem Rechenzentrum steht. Dort will er SSH umkonfigurieren und stoppt dazu den sshd. Würde systemd nun alle Childprozesse beenden, wäre die Loginsession auch weg. Viel schlimmer ist dann aber, daß er sich nicht einmal erneut einloggen kann, weil der Dienst ja beendet wurde, du kommst also an die Kiste gar nicht mehr ran.

In diesem Fall ist es wohl besser, die Childprozesse leben zu lassen und in Kauf zu nehmen, daß man bei einem Reboot einen hängeden Client hat, den man aber einfach lokal auf dem Client mit kill abschiessen kann.

[heisenberg]

Ob das jetzt gut oder schlecht ist, war jetzt nicht unbedingt die Frage, die ich aufwerfen wollte, sondern nur was vielleicht abläuft.

Mir hat das auch nicht gefallen, das per Default Hintergrundprozesse von systemd beim logout aufgeräumt werden.