Stopping NMB time out

Hinweis: In dem Thema Stopping NMB time out gibt es 21 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • @Sauerland: Domain Master = yes hat nichts gebracht. Hänger trat trotzdem auf.


    Zur weiteren Analyse habe ich mir jetzt den Source Code des nmbd von git.samba.org geholt und analysiert. Meine Erkenntnisse:

    • nmbd installiert gleich beim Start einen SIGTERM Handler. Wenn dieser gerufen wird, dann erfolgt unmittelbar danach der Aufruf von terminate, was die Log-Ausgabe aus dem Gutfall zur Folge hat (Got SIGTERM: going down...).
    • Der asyncdns Prozess wird in zwei Fällen gestartet:

      • Beim Start von nmbd
      • In einem zyklischen Test, der prüft, ob der asyncdns Prozess noch läuft. Ist dies nicht der Fall, wird er neu gestartet

    Diese Vorgänge habe ich anhand der Version 4.7.10 analysiert, die Leap 15.0 verwendet. Die fraglichen Codestellen sind aber auch im aktuellen master nicht geändert. Jetzt versuche ich, daraus ein paar Schlüsse zu ziehen:

    • Der nmbd bekommt im Schlechtfall kein SIGTERM, denn sonst würde ich die Logausgabe der Signal Handlers sehen
    • Allerdings stirbt im Schlechtfall der asyncdns Prozess, denn dieser wird über den oben genannten zyklischen Test neu gestartet. Es handelt sich dabei nicht um den Neustart des gesamten nmbd, denn dabei wären noch andere Logmeldungen zu sehen.
    • Also könnte man annehmen, dass aus irgendeinem komischen Grund das SIGTERM Signal nicht an den nmbd Daemon geht, sondern an dessen Child-Prozess asyncdns.

    Ich habe aber keine Ahnung, wie das zustande kommen soll. Wie genau merkt sich systemd, an welchen Prozess das SIGTERM zugehen hat? Wo ist überhaupt aufgeführt, wie die Prozesse zu beenden sind? Ich habe bisher nur /etc/systemd/system/multi-user.target.wants/nmb.service gefunden, und da stehen nur Anweisungen für Start und Reload. Wo steht, wie gestoppt wird? Wo merkt sich systemd die PIDs der laufenden Services?


    Zur Vollständigkeit diese Datei:

  • Viele solcher "Einstellungen" sind implizit.
    Wenn ein DienstA voraussetzt, dass DienstB bereits läuft, wird also zuerst DienstB, danach DienstA gestartet.
    Dabei ist schon impliziert, dass die Reihenfolge für den Shutdown umgekehrt ist.


    Dokumentiert ist das alles in vielen Manpages.
    Probiere ein man systemd<tab><tab> damit du siehst, was zu Lesen alles vor dir liegt.
    Alternativ kannst du auch im Freedesktop Wiki alles nachlesen.
    (kräftig scrollen bis zu:
    Manuals and Documentation for Users and Administrators

  • Danke für die Links. Daraus schließe ich:

    • systemd merkt sich die PID beim Starten. Wo braucht mich erst mal nicht zu interessieren
    • Ein SIGTERM zu senden ist einfach der Default. Deshalb steht dazu nichts in nmb.service

    Bringt mich in Summe aber noch nicht weiter. Hmm. In systemd-Debugging einzusteigen traue ich mich noch nicht und weiß auch nicht, ob das wirklich sinnvoll wäre. Wenn mir systemd aber sagen könnte, welche Signale er an welche Prozesse schickt, dann wäre das hilfreich.

  • Es gab einen Bug (nmb.service: State 'stop-sigterm' timed out) bei einem Upgrade auf openSUSE Leap 15.
    Hast du openSUSE Leap 15 neu installiert - oder gab es ein Upgrade?
    Lösung bei einem Distributions-Upgrade wäre dann Samba neu zu installieren (vorher "/etc/samba/smb.conf" sichern).
    Mal schauen, ob ich den Link noch finde...

    Einmal editiert, zuletzt von sterun ()

    Für den Inhalt des Beitrages 127838 haftet ausdrücklich der jeweilige Autor: sterun

  • Ebenso zusätzlich zu meinem Vorposter:


    Code
    cat /etc/systemd/system/multi-user.target.wants/nmb.service

    Edit:
    Uups, erledigt Beitrag #11

    Für den Inhalt des Beitrages 127839 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Es gab einen Bug (nmb.service: State 'stop-sigterm' timed out) bei einem Upgrade auf openSUSE Leap 15.
    Hast du openSUSE Leap 15 neu installiert - oder gab es ein Upgrade?
    Lösung bei einem Distributions-Upgrade wäre dann Samba neu zu installieren (vorher "/etc/samba/smb.conf" sichern).
    Mal schauen, ob ich den Link noch finde...

    Das war eine Neuinstallation. Trotzdem wäre der Link interessant. Vielleicht gibt die Lösung Hinweise darauf, welcher Fehlermechanismus da vorlag. Das könnte mir evtl. auch helfen.

  • Stoppe samba:

    Code
    systemctl stop smb.service


    stoppe nmbd:


    Code
    systemctl stop nmb.service

    starte nmbd per Hand:


    Code
    nmbd -FS

    Lass ein paar Sekunden laufen, abbrechen mit STRG+C


    Poste die Ausgabe.

    Für den Inhalt des Beitrages 127841 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Die Ausgabe ist:

    Was ich jetzt auch noch probiere ist, dass ich per Skript beim Hoch- und Runterfahren die Ausgaben von systemctl status nmb.service mitlogge. Ich habe irgendwie den Vedacht, das systemd in manchen Fällen den Hauptprozess mit dem asyncdns Prozess verwechselt. Da könnte die Ausgabe der PID, die systemd für die Main PID hält, aufschlussreich sein.


    Jetzt aber euch allen einen guten Rutsch! Ich denke, das Problem lösen wir nächstes Jahr :)

  • Zitat von sterun

    Ich würde Samba einfach neu einrichten

    Damit warte ich noch. Mein Verdacht liegt momentan eher auf systemd als auf Samba.



    Zitat von sterun

    DefaultTimeoutStopSec=10s

    An sowas hab ich schon gedacht, wusste nur nicht, wo ich das machen kann. Danke für den Hinweis! Aber auch das ist ja eher eine Vertuschung des Problems als eine Beseitigung. Trotzdem: Kann im täglichen Betrieb hilfreich sein! Momentan mache ich noch meine Status-Logs beim Hoch- und Runterfahren und warte auf den nächsten Hänger...


    Ergänzung: ist gerade eben passiert, aber der systemctl status nmb.service zeigt keinerlei Auffälligkeiten. Alles wie immer. Ich grüble weiter...



    Einfach mal testen...

    Puh, das ist mir vorerst zu komplex. Auch hier hätte ich gerne noch etwas mehr beobachtet und Hinweise gesammelt, bevor ich das große Besteck auspacke. Ich wüsste noch gar nicht, wonach ich suchen soll.