Wegen eines abgefallenen Netzwerkkabels sollen keine Programme gestoppt werden.

[alexander_ro]

Hallo ...

Mich Quält gerade die Frage warum werden wenn ein Netzwerkkabel abfällt alle Netzwerk Dienste gestoppt. Das ist höchst unpraktisch weil man dann den Rechner auch wenn der Übeltäter das Kabel wieder angesteckt nicht mehr erreichen kann. Ich muss mich von meinen Stuhl plagen und da hingehen den ausschalten und wieder einschalten mit dem zwar geringem aber vorhandenem Risiko eines Datenverlustes.

Es gab Zeiten da ging das Problemlos niemand kam auf die seltsame Idee wegen einem Carrier Verlust jede Netzwerkanwendung zu killen.

Kann man das abstellen?

Grüße
Alexander

[letzter3]

Hallo ...
Mich Quält gerade ... Ich muss mich von meinen Stuhl plagen und da hingehen ... mit dem zwar geringem aber vorhandenem Risiko eines Datenverlustes Gewichtsverlustes.

Sorry, der musste gerade sein.

[alexander_ro]

Das wäre kein Risiko eher ein Vorteil.

[letzter3]

Ich wollte den thread nicht kapern und entschuldige mich für die vorherige und jetzige Belästigung, da anscheinend die Antwort-notification eingeschaltet ist.
Ich halte mich ab sofort hier raus, da ich vom Thema keine Ahnung habe.

[mat6937]

Es gab Zeiten da ging das Problemlos ...

Welche Zeiten waren das? Wie hast Du damals und wie hast Du jetzt, das Zuweisen der IP-Adresse & Co. konfiguriert?

[alexander_ro]

Das Zeitalter vor systemd.
Die IP-Adressen sind nicht das Problem sondern das apache und ssh terminiert werden sobald die Netzwerkverbindung weg ist. Steckt man das Kabel wieder an geht das Netzwerk nur laufen halt keine Dienste mehr die werden nur terminiert aber nicht gestartet.

[schorsch_76]

So ein ähnliches Problem hatte ich bei einem Projekt auch mal. Da hab ich die Holzhammermethode angewandt. Cronjob der jede Minute prüft ob das Netzwerk da ist und es dann die notwendigen Jobs neu startet. Mehrere Klimmzüge und Versuche mit eventgesteuertem Neustart haben nicht zum Ziel geführt .....

[mat6937]

... ssh terminiert werden sobald die Netzwerkverbindung weg ist.

Teste mal temporär, ob das auch dann der Fall ist wenn Du in der "/etc/ssh/sshd_config":

Code: Alles auswählen

TCPKeepAlive no

konfigurierst.

[alexander_ro]

Ja das funktioniert natürlich mit einem Cronjob muss ich mal schauen wie ich das am besten mache.

Das mit dem TCPKeepAlive glaube ich nicht das es was bringt. Weil ja der ssh Prozess beendet wird nicht nur die Verbindung. Ich probiere es trotzdem mal ob sich was ändert. Kann das aber gerade nicht machen weil der Rechner aktuell gebraucht wird.

[unitra]

Die Applikation an

Code: Alles auswählen

0.0.0.0

binden oder

Code: Alles auswählen

::

für IPv6 . Das ist eine Applikationseinstellung, nicht jede Applikation hat die Möglichkeit an alle Schnittstellen gebunden zu werden, aber nicht wurdern wenn es nicht klappt. Softwareentwickler sind auch nur Menschen.

Hallo ...

Mich Quält gerade die Frage warum werden wenn ein Netzwerkkabel abfällt alle Netzwerk Dienste gestoppt. Das ist höchst unpraktisch weil man dann den Rechner auch wenn der Übeltäter das Kabel wieder angesteckt nicht mehr erreichen kann. Ich muss mich von meinen Stuhl plagen und da hingehen den ausschalten und wieder einschalten mit dem zwar geringem aber vorhandenem Risiko eines Datenverlustes.

Es gab Zeiten da ging das Problemlos niemand kam auf die seltsame Idee wegen einem Carrier Verlust jede Netzwerkanwendung zu killen.

Kann man das abstellen?

Grüße
Alexander

[mat6937]

Das mit dem TCPKeepAlive glaube ich nicht das es was bringt.

OK, aber auch wenn es was bringt, ist es als Dauerlösung nicht geeignet.
Versuch mal auch mit:

Code: Alles auswählen

net.ipv4.ip_nonlocal_bind = 1
net.ipv6.ip_nonlocal_bind = 1

in der /etc/sysctl.conf (oder gleichwertig).

Ich hatte mit dem sshd unter systemd auch Probleme, wenn der sshd nicht an allen Interfaces (d. h. nicht an lo) gelauscht hat. "ip_nonlocal_bind=1" hat geholfen.

EDIT:

Bei meinem sshd (... mit systemd, "ip_nonlocal_bind=1" und "ConfigureWithoutCarrier=true"für das Interface eth0) hat das Unterbrechen der LAN-Verbindung keinen Einfluss darauf, ob der sshd gestoppt wird oder nicht gestoppt wird. Z. B.:

Code: Alles auswählen

:~# dmesg -T | tail -n 6
[Fri Feb 12 05:24:25 2021] bcmgenet fd580000.ethernet eth0: Link is Down
[Fri Feb 12 05:24:39 2021] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[Fri Feb 12 05:24:44 2021] bcmgenet fd580000.ethernet eth0: Link is Down
[Fri Feb 12 05:24:50 2021] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[Fri Feb 12 05:25:35 2021] bcmgenet fd580000.ethernet eth0: Link is Down
[Fri Feb 12 05:25:42 2021] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

Code: Alles auswählen

:~# netstat -tlpen | grep -i ssh
tcp        0      0 192.168.178.33:22   0.0.0.0:*               LISTEN      0          16694      526/sshd   

Code: Alles auswählen

:~# systemctl status ssh
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-02-10 08:54:48 CET; 1 weeks 1 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 526 (sshd)
    Tasks: 4 (limit: 4915)
      CPU: 37.507s
   CGroup: /system.slice/ssh.service
           ├─ 526 /usr/sbin/sshd -D -4 -q

[/spoiler]

[alexander_ro]

Sorry ich musste mich erst um ein Problem mit einem beim booten nicht startenden dhcpd kümmern war da aber kein Debian. Ich habe aber hier in einem anderen Thread gelesen das das Problem hier auch vorkommt.

Ich bin aus den diversen Infos im Netz nicht richtig schlau geworden. Was bewirkt denn diese Einstellung (net.ipv4.ip_nonlocal_bind)?
Gehört das zur Kernel Konfiguration oder systemd?

[mat6937]

Was bewirkt denn diese Einstellung (net.ipv4.ip_nonlocal_bind)?
Gehört das zur Kernel Konfiguration oder systemd?

Ja, das ist eine Kernelkonfiguration (mit sysctl bzw. in dessen config).
Damit kann man einen Prozess auch dann an eine IP-Adresse binden, wenn diese IP-Adresse zum Zeitpunkt zu dem der Prozess aktiv wird, noch nicht zugewiesen worden ist (d. h. sie "existiert dann noch nicht").

[michaa7]

Hallo ...

Mich Quält gerade die Frage warum werden wenn ein Netzwerkkabel abfällt alle Netzwerk Dienste gestoppt. ...

Also hier bei mir (Debian / sid(uction) ist das nicht der Fall:

Scenario: User auf Desktop verbindet sich mit Laptop über "ssh <user>@laptop" in einem VT ausgeführt (beide Rechner sind über den Router verkabelt). Nach erfolgreichem Verbindungsaufbau ziehe ich das Netzwerkkabel des Laptops (die Verbindung ist jetzt im VT tot) und warte mehr als eine Minute bevor ich es wieder einstecke. Nach dem Einstecken kann ich im VT die Verbindung weiter betreiben.

Deiner Aussage nach hätte ja der sshd des LAptops sterben müssen ... was er nicht tat. Warum auch?

[alexander_ro]

Nicht ganz: es ist ein Server auf dem ein sshd läuft und der ist mit einem Switch verbunden. Der andere Rechner über ein WLAN auch mit dem Switch. Ob eine Minute reicht kann ich nicht sagen. Ich bekomme das nicht mit wenn mal wieder jemand das Kabel ausreist. Auf jeden Fall laufen dann die Netzwerkdienste nicht mehr. Um das festzustellen habe ich extra Monitor und Tastatur zu dem Rechner geschleppt und nachgesehen.

[michaa7]

...Ob eine Minute reicht kann ich nicht sagen. Ich bekomme das nicht mit wenn mal wieder jemand das Kabel ausreist. Auf jeden Fall laufen dann die Netzwerkdienste nicht mehr. Um das festzustellen habe ich extra Monitor und Tastatur zu dem Rechner geschleppt und nachgesehen.

Ja aber warum soll denn der sshd sterben? Maximal dürfte die Verbindung tot sein. Oder kann da ein Sicherheitsfeature das Kommando übernehmen? (Ich habe keine Ahnung von sowas !)

Hast du die config mal durchgeschaut ob es da eine Option gibt was bei Verbindungsabbruch passiert?
Steht was erhellendes im syslog? Da muß doch zumindest zu finden sein ob ein timeout oder ein kill oder was auch immer die Hand im Spiel hatte.

Mit der option -E log_file kannst du auch ein eigenes Log schreiben.

[alexander_ro]

@michaa7:
Ich vermute der systemd beendet die Prozesse die Netzwerk brauchen weil ja kein Netzwerk mehr da ist. Vergisst die aber dann zu starten wenn Netzwerk wieder da ist. Beim booten ist es ja ein ähnliches Problem. Ein dhcpd hat beim starten absolut kein Problem wenn das Netz nicht da ist. Das Problem haben die Init-Systeme heute eigentlich alle weil seit upstart und systemd alle den angebliche tollen Funktionen nacheifern ...

Netzwerk unter Linux war mal richtig solide und Problemlos wenn mal der Treiber für die Netzwerkkarte lief. Seit da Konzerne und diverse Milliardäre drinnen herumpfuschen ist es nicht mehr wirklich besser als Windows. Linux hat durch die Kommerzialisierung viel verloren und wird mit der Schwachsinnigen Idee Rust als Kernel Programmiersprache zu integrieren das letzte Solide Teil verlieren. Torvald ist nach seiner Gehirnwäsche Pause auch keiner mehr der sich für den Erhalt der Kernel Qualität einsetzt. Schade darum aber wenn man von der gesammelten Konzern und Presse Lobby gehetzt wird weil man die Wahrheit sagt ist es nicht verwunderlich.

Nach dem Unsinn mit den Binär Logfiles habe ich nicht wirklich den Überblick über das was in den Logfiles steht. Ist recht dürftig was diese Systemd Kommandos als Logdaten zur Verfügung stellen. Früher haben die Programm mehr Infos geliefert. Vielleicht tun die das immer noch und werden verschluckt oder weiss der Geier wo gespeichert.

@mat6937:
Ich habe das mal so gemacht wie Du vorgeschlagen hast. Für mich klingt das aber mehr wie eine Funktion die zum Programmstart gebraucht wird und weniger für das weiterlaufen. Ist aber nur so eine Vermutung von mir ich hoffe es hilft. Aktuell ist jetzt beim Testen nichts schief gegangen ich werde das mal beobachten.

[michaa7]

@michaa7:
Ich vermute der systemd beendet die Prozesse die Netzwerk brauchen weil ja kein Netzwerk mehr da ist. Vergisst die aber dann zu starten wenn Netzwerk wieder da ist. ...

Das ist aber eine gewagte Vermutung.

Und wenn systemd *vergäße* etwas zu tun, dann wäre das ein Bug ... was ich aber als Ursache anzweifle angesichts der Tatsache, dass systemd bei mir weder etwas vergißt noch killt, auch nicht nach mehr als zweistündiger Trennung wie ich gestern nochmals getestet habe.

[mat6937]

... und weniger für das weiterlaufen.

Das kommt drauf an was man mit "weiterlaufen" meint. Kann der einmal gestartete und funktionierende sshd weiterlaufen, wenn das Interface mit der einzigen IP-Adresse die der sshd benutzt, down (oder no-carrier hat) ist?
Entferne jetzt mal das Netzkabel und schau mit Bildschirm und Tastatur nach, was der sshd jetzt macht.

[alexander_ro]

Deshalb ja auch meine Frage hier. Ich weiss nur sicher das es in der vor systemd Ära solche Probleme nicht gab. Aber wer ausser systemd und den Usern Pfuscht im laufenden System herum?
User kommen in dem Fall eher nicht in Frage weil das System ohne Netzwerk für die User nicht mehr zu erreichen war.

Also das der systemd beim booten vergisst das es ein loopback Device gibt und deshalb Netzwerkdienste eigentlich immer gestartet werden sollten ist zumindest eine erwiesene Tatsache. Netzwerk als lokales Mittel zur Kommunikation ist nun wirklich nichts seltenes. Dafür wurden vor langer Zeit extra die Domainsockets erfunden die dann sogar nur lokal zu erreichen wären.

Das ganze boot System soll Dinge starten die man gestartet haben will und gut ist es. Relativ Dummen Programmen die nicht mal wissen was die Anwendung tut und der User will sollte es verboten sein Entscheidungen im Namen der Anwendung/User zu treffen. Egal ob booten oder laufendes System.

[mat6937]

Also das der systemd beim booten vergisst das es ein loopback Device gibt und deshalb Netzwerkdienste eigentlich immer gestartet werden sollten ist zumindest eine erwiesene Tatsache.

Ist dein sshd so konfiguriert, dass dieser beim Start, auf allen Interfaces lauscht? Wenn ja, lauscht der sshd nach dem entfernen und wieder einstecken das Kabels, evtl. nur noch auf dem loopback device und ist deshalb aus dem LAN nicht mehr erreichbar?

[alexander_ro]

Vorher war der sshd Prozess nicht mehr da.
Weiterlaufen meint das der sich nicht beendet und tut was er soll ... also über das Netzwerk erreichbar ist.
Der sshd läuft weiter wenn man die Schnittstelle komplett stoppt und lauscht wieder an dem Interface sobald es wieder da ist. So macht er es jetzt zumindest. So sollte es auch sein.

Wenn ich mich richtig erinnere muss ein Programm nicht mal mit dem Lauschen aufhören. Sollte es die Schnittstelle benutzen wollen würde es eine Fehlermeldung vom Kernel bekommen.

[mat6937]

So macht er es jetzt zumindest.

OK. Wie hast Du das geprüft? Ist die PID des sshd vor dem Entfernen und nach dem wieder einstecken des LAN-Kabels, unverändert geblieben?

Code: Alles auswählen

ps -fC sshd
pidof sshd
systemctl status ssh

?

[alexander_ro]

Nein die PID habe ich nicht geprüft. Ich habe eine lokal Verbindung zum sshd aufgebaut und das ging.

[mat6937]

Nein die PID habe ich nicht geprüft.

OK. Aber die PID ist der genauere Hinweis, ob der sshd vom entfernen des Kabels, irgendwie beeinflusst worden ist.