Konsolenverhalten wheezy u. jessie-lite bei shutdown

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    seit einiger Zeit beobachte ich ein unterschiedliches Verhalten der Konsole, wenn ich ein System mit wheezy oder jessie-lite remote per ssh über die Konsole herrunterfahre oder reboote.

    Unter Ubuntu richte ich über die Konsole eine ssh-Verbindung zu einem pi ein, auf dem wheezy oder jessie-lite (aktuelle Version) laufen.

    Gebe ich bei dem wheezy-System über die Konsole "sudo shutdown -h now" ein, erhalte ich nach kurzer Zeit ein "Connection closed".

    Bei gleicher Vorgehensweise im jessie-lite-System gibt es keine Meldung und ich bleibe anscheinend auf dem Remotesystem. Befehle lassen sich aber nicht mehr absetzen.

    Schliesst man die Konsole, erscheint ein Hinweis, dass noch ein Prozess ausgeführt wird. Der pi ist dann aber schon längst heruntergefahren.

    Kennt jemand den Grund für das unterschiedliche Verhalten?

    Gruß

    Hilmar_Nois

  • Konsolenverhalten wheezy u. jessie-lite bei shutdown? Schau mal ob du hier fündig wirst!


  • Kennt jemand den Grund für das unterschiedliche Verhalten?

    Kann ich nicht bestätigen bzw. das wird daran liegen wie Du sshd-Server und ssh-Client konfiguriert hast.

    Hier wheezy (Server) und Ubuntu (Client):

    Code
    ~ $ sudo shutdown -r now
    [sudo] password for xxxxx: 
    
    
    Broadcast message from xxxx@yyyy (pts/0) (Sun Mar 19 21:57:00 2017):
    
    
    The system is going down for reboot NOW!
    xxxx@yyyy ~ $ Connection to 192.168.178.## closed by remote host.
    XX@YYYY:~$

    Hier jessie-lite (TEST-Server) und Ubuntu (Client):

    Code
    :~ $ sudo shutdown -r now
    
    
    Broadcast message from pi@raspberrypi on pts/0 (Sun 2017-03-19 21:56:38 CET):
    
    
    The system is going down for reboot NOW!
    
    
    pi@raspberrypi:~ $ XX@YYYY:~$

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Das Problem ist bekannt, der SSH Dienst trennt die Verbindung nicht ordnungsgemäß bzw rechtzeitig, hängt mit systemd zusammen, und kann wie folgt gefixt werden:

    Code
    systemctl disable ssh.service
    systemctl enable ssh.socket

    Siehe dazu auch https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636


    Kann ich nicht bestätigen

    Das Problem hatte ich auch, mit einem aktuellen und unveränderten Raspbian-Jessie-Lite Image. Wie gesagt liegt das an systemd: Netzwerk wird früher beendet als ssh.service


  • ... liegt das an systemd: Netzwerk wird früher beendet als ssh.service

    Das ist nicht richtig. Wenn ich auf meinem Ubuntu-ssh-Client:

    Code
    sudo tcpdump -vvveni <Interface> port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'


    starte und danach auf dem PI mit jessie-lite:

    Code
    sudo shutdown -r now


    ausführe, dann zeigt mir tcpdump auf dem Ubuntu-ssh-Client noch Folgendes vom sshd-Server an:

    Code
    23:58:22.920629 b8:27:eb:##:##:## > 00:1b:77:xx:xx:xx, ethertype IPv4 (0x0800), length 54: (tos 0x58, ttl 64, id 4673, offset 0, flags [DF], proto TCP (6), length 40)
       192.168.178.43.22 > 192.168.178.21.52971: Flags [R], cksum 0x431f (correct), seq 3545028570, win 0, length 0


    Das zeigt, dass das Netzwerk des PIs nicht früher als ssh.service beendet wird und vom sshd-Server eine reset-Nachricht beim ssh-Client noch ankommt (... was dazu führt, dass der ssh-Client auf Ubuntu richtig beendet wird).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Es ist mir bewusst dass das auf anderen Systemen funktioniert wie es soll, bei Raspbian hab ich das Problem aber schon mal gehabt und mit dem letzten Image ist es wieder so.

    Lies einfach den Link...


    Ansonsten erklär Du doch bitte den Unterschied zwischen ssh.service und ssh.socket, und wieso es mit letzterem 'wieder' funktioniert? :-/


  • Es ist mir bewusst dass das auf anderen Systemen funktioniert wie es soll, bei Raspbian hab ich das Problem aber schon mal gehabt und mit dem letzten Image ist es wieder so.

    Lies einfach den Link...

    Dass das durch aus richtig ist beweißt auch ein tatsächlicher Versuch mit Raspbian-lite.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Du siehst nicht deinen Fehler, oder?

    Du testest das mit einem System was von dem Problem nicht betroffen ist. Ergo liefert dir tcpdump korrekte Werte und Dein Client wird auch korrekt getrennt. Das beweißt aber nichts.

    Lies daher bitte einfach noch mal den Thread aufmerksamer - und den Link in Beitrag#3

    Betroffene Systeme schicken definitiv keine "reset-Nachricht".

  • Moin,

    ja, es stimmt was meigrafd geschrieben hat. Nach der Änderung bekommt man die Meldung und wird getrennt.

    Aber es wird die sshd_config nicht mehr beachtet.

    Wenn man, wie ich, auf einen anderen Port als 22 lauscht, kann man das schnell feststellen.

    Um das zu ändern muss man wieder in der ssh.socket rummachen. Ist aber, wahrscheinlich, nicht updatefest.

    Gruss Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.


  • Ansonsten erklär Du doch bitte den Unterschied zwischen ssh.service und ssh.socket, und wieso es mit letzterem 'wieder' funktioniert? :-/

    Ich kenne den Unterschied nicht bzw. ich habe mit ssh.socket nicht testen müssen, weil es mit ssh.service bei meiner Konstellation (PI mit jessie-lite und ssh-Client mit Ubuntu) auch so schon immer funktioniert hat.

    Der TE und jeder andere auch, kann ja (bei Interesse) auf seinem ssh-Ubuntu-Client (... bzw. auf dem PI mit ssh.service und/oder ssh.socket) und:

    Code
    sudo tcpdump -vvveni <Interface> port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'


    (oder gleichwertig)
    feststellen, ob nach dem shutdown auf dem PI, vom sshd-Server noch eine reset-Nachricht beim ssh-Client ankommt (... und wenn ja, wie der ssh-Client darauf reagiert).

    EDIT:

    Kleiner Hinweis am Rande: Ich habe zusätzlich zur ssh-Verbindung zwischen PI und Ubuntu-Client, auch (parallel) eine telnet-ssl-Verbindung zwischen PI und Ubuntu-Client hergestellt. Wenn ich dann auf dem Ubuntu-Client, über die ssh-Verbindung das "shutdown -r now" ausführe, wird die telnet-ssl-Verbindung _sofort_ beendet, aber nicht sofort auch die ssh-Verbindung (... über die ja noch die reset-Nachricht zum Ubuntu-Client gesendet wird).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. März 2017 um 00:40)


  • Das Problem kannst du hier sehen ...

    Naja, da sieht man auch nur das, was Du oben auch schon beschrieben hast.

    Interessant wäre zu sehen bzw. zu wissen, ob und welche Daten (sofort) nach der Eingabe von "sudo reboot", vom sshd-Server deines PIs (1. mit ssh.service und 2. auch mit ssh.socket) an deinen ssh-Client gesendet werden (oder auch nicht gesendet werden).

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. März 2017 um 09:24)

  • Servus rpi444,
    also ich kann das Phänomen ebenfalls nachvollziehen.
    Allerdings verhält es sich bei shutdown -r und shutdown .h unterschiedlich:

    Code
    pi@pi-robot:~ $ 
    pi@pi-robot:~ $ sudo shutdown -r now
    packet_write_wait: Connection to 192.168.1.126 port 22: Broken pipe
    dirk@mars:~$


    Nach Drücken von <RETURN> kommt die brokenpipe Meldung und der Prompt des Client erscheint wieder.
    Bei einem shutdown -h allerdings

    Code
    pi@pi-robot:~ $ 
    pi@pi-robot:~ $ sudo shutdown -h now


    ist die Verbindung tot ... hängt also, und ich muss das Fenster schliessen.

    Client ist ein Ubuntu Laptop, Host in dem Fall ein Pi Zero mit der aktuellsten Jessie Lite Version (2017-03-02-raspbian-jessie-lite.img)

    cu,
    -ds-


  • ist die Verbindung tot ... hängt also, und ich muss das Fenster schliessen.

    Client ist ein Ubuntu Laptop, Host in dem Fall ein Pi Zero mit der aktuellsten Jessie Lite Version (2017-03-02-raspbian-jessie-lite.img)

    OK, könntest Du in einem anderen Fenster deines Ubuntu-Laptops, vor dem "sudo shutdown -r now":

    Code
    sudo tcpdump -vvveni <Interface> port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'


    (Interface musst Du entsprechend deinem Ubuntu-Laptop anpassen) und schauen was tcpdump auch noch bis zu 2 Minuten (... weil die Ausgabe durch tcpdump auch verzögert statt finden kann) nach dem reboot anzeigt?

    Siehe vor dem reboot, mit z. B. "sudo netstat -tlpen | grep -i :22" auf deinem Laptop auch den source-Port des ssh-Clienten (zwecks Vergleich mit der evtl. Ausgabe von tcpdump).


    Automatisch zusammengefügt:


    Bei einem shutdown -h allerdings

    Code
    pi@pi-robot:~ $ sudo shutdown -h now


    ist die Verbindung tot ... hängt also, ...

    BTW: Evtl. auch mit:

    Code
    sudo shutdown -h +1


    (statt "now") testen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. März 2017 um 10:22)

  • Also,
    wenn ich einen shutdown -r ausführe und parallel dazu auf dem Laptop den tcpdump, dann kommt als Ausgabe:

    Code
    dirk@mars:~$ sudo tcpdump -vvveni enp0s25 port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'
    tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
    10:14:23.653468 7c:dd:90:9e:1e:5d > 8c:73:6e:dc:10:36, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 44368, offset 0, flags [DF], proto TCP (6), length 40)
       192.168.1.126.22 > 192.168.1.122.36806: Flags [R], cksum 0x834e (correct), seq 3227146258, win 0, length 0

    Die Ausgabe kommt allerdings erst, nachdem ich auf dem Laptop in dem Fenster, in dem ich die ssh-Verbindung aufgebaut hatte, <ENTER> gedrückt habe.

    Bei einem shutdown -h kommt

    Code
    dirk@mars:~$ sudo tcpdump -vvveni enp0s25 port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'


    nüscht ... auch nach zwei Minuten nix ...
    Wenn ich allerdings das Fenster schliesse, kommt der Reset ...

    Code
    10:24:09.026573 7c:dd:90:9e:1e:5d > 8c:73:6e:dc:10:36, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 42915, offset 0, flags [DF], proto TCP (6), length 40)
       192.168.1.126.22 > 192.168.1.122.36832: Flags [R], cksum 0x6363 (correct), seq 1857145228, win 0, length 0


    und netstat gibt aus:

    Code
    dirk@mars:~$ sudo netstat -tlpen | grep -i :22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          35825       1095/sshd       
    tcp6       0      0 :::22                   :::*                    LISTEN      0          35827       1095/sshd

    Ich installiere gerade tcpdump auf dem Zero ... das könnte ich über die serielle Konsole mal anschmeissen und während des shutdown -h durchlaufen lassen. Wie soll der tcpdump-Aufruf da aussehen?

    //EDIT: Zwischen shutdown -h now und shutdown -h +1 ist kein Unterschied im Verhalten festzustellen ...

    cu,
    -ds-


  • wenn ich einen shutdown -r ausführe und parallel dazu auf dem Laptop den tcpdump, dann kommt als Ausgabe:

    Code
    dirk@mars:~$ sudo tcpdump -vvveni enp0s25 port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'
    tcpdump: listening on enp0s25, link-type EN10MB (Ethernet), capture size 262144 bytes
    10:14:23.653468 7c:dd:90:9e:1e:5d > 8c:73:6e:dc:10:36, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 44368, offset 0, flags [DF], proto TCP (6), length 40)
       192.168.1.126.22 > 192.168.1.122.36806: Flags [R], cksum 0x834e (correct), seq 3227146258, win 0, length 0

    Die Ausgabe kommt allerdings erst, nachdem ich auf dem Laptop in dem Fenster, in dem ich die ssh-Verbindung aufgebaut hatte, <ENTER> gedrückt habe.

    Bei einem shutdown -h kommt

    Code
    dirk@mars:~$ sudo tcpdump -vvveni enp0s25 port 22 and 'tcp[tcpflags] & (tcp-rst) != 0'


    nüscht ... auch nach zwei Minuten nix ...
    Wenn ich allerdings das Fenster schliesse, kommt der Reset ...

    Code
    10:24:09.026573 7c:dd:90:9e:1e:5d > 8c:73:6e:dc:10:36, ethertype IPv4 (0x0800), length 60: (tos 0x10, ttl 64, id 42915, offset 0, flags [DF], proto TCP (6), length 40)
       192.168.1.126.22 > 192.168.1.122.36832: Flags [R], cksum 0x6363 (correct), seq 1857145228, win 0, length 0

    Na das ist doch schon was. 1., mit dem "shutdown -r/-h" wird die Verbindung vom sshd-Server zum ssh-Client _nicht sofort_ unterbrochen und 2., dass hier der ssh-Client und seine "Fenster" mit der vom Server erhaltenen reset-Nachricht nicht umgehen kann, liegt m. E. nur am ssh-Client.


    und netstat gibt aus:

    Code
    dirk@mars:~$ sudo netstat -tlpen | grep -i :22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          35825       1095/sshd       
    tcp6       0      0 :::22                   :::*                    LISTEN      0          35827       1095/sshd


    Ich habe die -a-Option vergessen, denn so sieht man nicht die Verbindungen:

    Code
    sudo netstat -tlpena | grep -i :22


    Ich installiere gerade tcpdump auf dem Zero ... das könnte ich über die serielle Konsole mal anschmeissen und während des shutdown -h durchlaufen lassen. Wie soll der tcpdump-Aufruf da aussehen?


    Eigentlich braucht man hier tcpdump auf dem PI nicht, denn es geht ja darum, ob und wann eine Nachricht vom Server versendet wird und beim Client ankommt. Aber wenn Du tcpdump auch auf dem PI probieren willst, dann genau so wie auf dem Client. Nur das Interface musst Du evtl. anpassen.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample


  • ... wird das Problem gelöst?

    Wenn Du bei evtl. "Problemen", die SD-Karte deines PIs mit einem anderen Gerät editieren kannst, dann versuch mal (als Test) folgende Konfigurationen auf deinem PI:
    In der /etc/sysctl.conf den Eintrag:

    Code
    net.ipv4.tcp_ecn = 1


    und in der /etc/ssh/sshd_config den Eintrag:

    Code
    IPQoS af23 af23


    (... aber ohne ssh.socket aktiv; d. h. nur mit aktiviertem ssh.service).
    Zwecks Wirksamkeit:

    Code
    sudo systemctl restart ssh
    sudo sysctl -p


    ausführen (oder reboot des PIs) und danach testen ob die "Fenster" beim Client nach dem "shutdown ... /reboot" auch noch hängen. Danach auch "tos" in der Ausgabe von tcpdump (auf dem Client) beachten.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ok, Nachtrag:

    netstat auf dem Ubuntu-client

    Code
    dirk@mars:~$ sudo netstat -tlpena | grep -i :22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          35825       1095/sshd       
    tcp        0      0 192.168.1.122:37060     192.168.1.126:22        VERBUNDEN   1000       44910       5965/ssh        
    tcp6       0      0 :::22                   :::*                    LISTEN      0          35827       1095/sshd       
    dirk@mars:~$

    Aber: tcpdump auf dem Pi ...

    scheint aber nix zu bringen, weil der tcpdump wohl eher abgewürgt wird, als der sshd ...

    Der netstat auf dem Client zeigt nach dem shutdown -r erstmal

    Code
    dirk@mars:~$ sudo netstat -tlpena | grep -i :22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          35825       1095/sshd       
    tcp        0      0 192.168.1.122:37086     192.168.1.126:22        VERBUNDEN   1000       46573       6045/ssh        
    tcp6       0      0 :::22                   :::*                    LISTEN      0          35827       1095/sshd


    und wenn ich nach einer Weile im ssh-Fenster <ENTER> drücke und die "broken pipe" Meldung kommt

    Code
    dirk@mars:~$ sudo netstat -tlpena | grep -i :22
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          35825       1095/sshd       
    tcp6       0      0 :::22                   :::*                    LISTEN      0          35827       1095/sshd       
    dirk@mars:~$

    Wenn ich jetzt die von meigrafd vorgeschlagene Fehlerbehebung mache

    Code
    systemctl disable ssh.service
    systemctl enable ssh.socket


    dann ... ja dann geht's auch nicht ...
    Da hängt der shutdown -h genauso wie vorher.

    Wenn ich aber das wieder rückgängig mache,

    Code
    systemctl disable ssh.socket
    systemctl enable ssh.service

    dann klappt's auch beim shutdown -h

    Code
    pi@pi-robot:~ $ sudo shutdown -h now
    Connection to pi-robot closed by remote host.
    Connection to pi-robot closed.
    dirk@mars:~$

    Ich denke, zum Beheben würde ein

    Code
    systemctl disable ssh.service
    systemctl enable ssh.service


    reichen. Vermutlich stimmt da irgendeine Einstellung nicht.

    cu,
    -ds-


  • Der netstat auf dem Client zeigt nach dem shutdown -r erstmal


    BTW: Die Ausgabe von "sudo netstat -tlpena | grep -i :22" wird nur einmal und nur vor dem shutdown benötigt, damit man den "Source-"Port des ssh-Clienten mit der Ausgabe von tcpdump vergleichen kann.


    Ich denke, zum Beheben würde ein

    Code
    systemctl disable ssh.service
    systemctl enable ssh.service


    reichen. Vermutlich stimmt da irgendeine Einstellung nicht.

    Naja, man will ja nicht nur für ssh/sshd eine Lösung, sondern auch für evtl. andere Verbindungen (telnet-ssl, ...) zwischen PI und einem Client-PC/Laptop. Diese anderen Verbindungen sollen ja nach einem shutdown, auch nicht "hängen".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (20. März 2017 um 11:19)

  • Also telnet hatte ich auf dem Zero nachinstalliert. Da klappt das:


    sowohl mit shutdown -r als auch mit shutdown -h

    cheers,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!