[erledigt] beim Herunterfahren automatisch aus ssh Ausloggen

[smutbert]

Hi,

wenn ich per ssh wo eingeloggt bin und ebendiesen Computer herunterfahre, passiert es manchmal, dass die Meldung (sinngemäß)

Host SSH-Server hat die Sitzung beendet.

kommt und ich wieder auf dem lokalen Terminal lande, aber meistens bleibe ich in der SSH-Sitzung hängen und muss ssh killen, um wieder herauszukommen. Das ist jetzt auch nicht besonders schlimm, aber ich bekomme einfach nicht heraus wovon das abhängt. Meine ursprüngliche Vermutung, dass er die Netzwerkinterfaces deaktiviert bevor sshd beendet wird, scheint mir beim abhängigkeitsbasierten Starten und Stoppen von Diensten (systemd) recht unwahrscheinlich, oder?

lg smutbert

[dirk11]

Ich kenne dieses Verhalten von Squeeze, dort hat ein Strg-C gereicht, um wieder auf der lokalen Konsole zu landen. Unter Wheezy habe ich das Problem nicht mehr beobachtet, jedenfalls nicht in der Intensität.

[smutbert]

Hm, bei mir ist es eher umgekehrt - in älteren Debianversionen wurde die Sitzung vom Server (meistens) beendet, jetzt mit wheezy und jessie, funktioniert es nur mehr selten so.

[smutbert]

Beim Untersuchen der ganzen Geschichte sind mir einige Kleinigkeiten aufgefallen, ich weiß nur noch nicht, ob es Zufall ist. Wie würdet ihr diesen Abschnitt der manpage von halt interpretieren?

halt notes that the system is being brought down in the file /var/log/wtmp, and then either tells the kernel to halt,
reboot or power-off the system.

If halt or reboot is called when the system is not in runlevel 0 or 6, in other words when it's running normally,
shutdown will be invoked instead (with the -h or -r flag). For more info see the shutdown(8) manpage.

The rest of this manpage describes the behaviour in runlevels 0 and 6, that is when the systems shutdown scripts are
being run.

also vor allem das mit den Runleveln 0 und 6… das heißt doch, dass halt und shutdown -h now auf das gleiche hinauslaufen?

[smutbert]

habe das Thema als erledigt markiert, weil ich entdeckt habe, dass das Hängenbleiben in der toten SSH-Sitzung hauptsächlich bei Verwendung des network-managers auftritt, aber nicht oder selten, wenn ich das nackte ifupdown verwende. Daraus schließe ich, dass es, wenn es auftritt, doch nur daran liegt, dass die Netzwerkinterfaces deaktiviert werden noch bevor der ssh-server beendet wurde.

In den .service-Dateien für systemd sowohl von sshd wie auch network-manager habe ich auf die Schnelle aber auch keine Möglichkeit gefunden anzugeben, dass sshd von network-manager abhängig ist (was ja genau genommen so auch gar nicht richtig wäre…)

[Cae]

Man kann SSH-Sitzungen, die aus welchen Gruenden auch immer haengen geblieben sind, per ~. beenden. Damit das ~-Zeichen erkannt wird, muss direkt davor ein Zeilenumbruch kommen, d.h. es ist <cr>~. zu druecken. Allerdings koennte das <cr> dabei einen (halb fertigen) Befehl in der entfernten Shell ausloesen, sodass letztendlich <c-c><cr>~. ratsam ist.

Falls das Netzwerk tot geht, bevor die Sitzung sauber geschlossen wird, bleibt der SSH-Client bis zum Ablauf des TCP-Timeouts im lokalen Terminal haengen, was durchaus ein paar Minuten dauert. Er reagiert scheinbar nicht auf Eingaben, aber das tut er auch sonst nicht, denn die Zeichen werden bei laufender Verbindung vom SSH-Server auf's Terminal gedruckt und nicht innerhalb des Clients.

Gruss Cae

[dirk11]

sodass letztendlich <c-c><cr>~. ratsam ist.

Was ist das bitte? cr~. ist klar: Return, Tilde, Punkt. Aber was ist c-c?

[4A4B]

c-c entspricht der Emacs Key Notation:

http://www.emacswiki.org/emacs/EmacsKeyNotation

... bedeutet also Strg + C

[smutbert]

Danke für die Tastenkombinationen, das mit der Tilde wußte ich noch nicht.

Aber der zweite Absatz widerspricht meinen Erfahrungen. Ich hatte (weil ich es genau wissen wollte ) nach dem Herunterfahren des SSH-Servers schon stundenlang SSH-Clients am laufen, die die Hoffnung den Server doch wieder zu erreichen nicht aufgegeben haben.
Erst wenn der Server tatsächlich wieder da ist (aber von der SSH-Sitzung natürlich nichts mehr weiß), bricht der Client mit "broken pipe" ab.

[dirk11]

Erst wenn der Server tatsächlich wieder da ist (aber von der SSH-Sitzung natürlich nichts mehr weiß), bricht der Client mit "broken pipe" ab.

Das allerdings kenne ich auch, und zwar bei ssh-Verbindungen zu meinen openWRT-Routern, da verhält es sich genauso.