Stopping NMB time out

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

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:

    Quellcode: nmb.service

    1. [Unit]
    2. Description=Samba NMB Daemon
    3. After=network.target
    4. [Service]
    5. Type=notify
    6. NotifyAccess=all
    7. Environment=KRB5CCNAME=/run/samba/krb5cc_samba
    8. EnvironmentFile=-/etc/sysconfig/samba
    9. ExecStart=/usr/sbin/nmbd --foreground --no-process-group $NMBDOPTIONS
    10. ExecReload=/usr/bin/kill -HUP $MAINPID
    11. [Install]
    12. WantedBy=multi-user.target
    Alles anzeigen

    Für den Inhalt des Beitrages 127811 haftet ausdrücklich der jeweilige Autor: letsfindaway

  • 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
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 127824 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • 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.

    Für den Inhalt des Beitrages 127836 haftet ausdrücklich der jeweilige Autor: letsfindaway

  • 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...
    Zitat Albert Einstein:
    "Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit,
    aber bei dem Universum bin ich mir noch nicht ganz sicher."

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von sterun ()

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

  • Ebenso zusätzlich zu meinem Vorposter:

    Quellcode

    1. cat /etc/systemd/system/multi-user.target.wants/nmb.service
    Edit:
    Uups, erledigt Beitrag #11
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

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

  • sterun schrieb:

    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.

    Für den Inhalt des Beitrages 127840 haftet ausdrücklich der jeweilige Autor: letsfindaway

  • Stoppe samba:

    Quellcode

    1. systemctl stop smb.service

    stoppe nmbd:

    Quellcode

    1. systemctl stop nmb.service
    starte nmbd per Hand:

    Quellcode

    1. nmbd -FS
    Lass ein paar Sekunden laufen, abbrechen mit STRG+C

    Poste die Ausgabe.
    Links in dieser Signatur bitte zum Lesen anklicken!

    Code-Tags <<<Klick mich
    zypper <<<Klick mich
    Netzwerkprobleme <<<Klick mich

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

  • Die Ausgabe ist:

    Quellcode

    1. gepard:~ # systemctl stop smb.service
    2. gepard:~ # systemctl stop nmb.service
    3. gepard:~ # nmbd -FS
    4. nmbd version 4.7.10-git.124.8d97fe90926lp150.3.9.1-SUSE-oS15.0-x86_64 started.
    5. Copyright Andrew Tridgell and the Samba Team 1992-2017
    6. Registered MSG_REQ_POOL_USAGE
    7. Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
    8. rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
    9. started asyncdns process 3124
    10. added interface eth0 ip=192.168.178.50 bcast=192.168.178.255 netmask=255.255.255.0
    11. making subnet name:192.168.178.50 Broadcast address:192.168.178.255 Subnet mask:255.255.255.0
    12. making subnet name:UNICAST_SUBNET Broadcast address:192.168.178.50 Subnet mask:192.168.178.50
    13. making subnet name:REMOTE_BROADCAST_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0
    14. making subnet name:WINS_SERVER_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0
    15. STATUS=daemon 'nmbd' finished starting up and ready to serve connections
    16. become_domain_master_browser_wins:
    17. Attempting to become domain master browser on workgroup WORKGROUP, subnet UNICAST_SUBNET.
    18. become_domain_master_browser_wins: querying WINS server from IP 192.168.178.50 for domain master browser name WORKGROUP<1b> on workgroup WORKGROUP
    19. become_domain_master_stage1: Becoming domain master browser for workgroup WORKGROUP on subnet UNICAST_SUBNET
    20. check_for_master_browser_fail: Forcing election on workgroup WORKGROUP subnet 192.168.178.50
    21. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    22. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    23. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    24. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    25. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    26. wins_registration_timeout: WINS server 127.0.0.1 timed out registering IP 192.168.178.50
    27. *****
    28. Samba server GEPARD is now a domain master browser for workgroup WORKGROUP on subnet UNICAST_SUBNET
    29. *****
    30. become_domain_master_browser_bcast:
    31. Attempting to become domain master browser on workgroup WORKGROUP on subnet 192.168.178.50
    32. become_domain_master_browser_bcast: querying subnet 192.168.178.50 for domain master browser on workgroup WORKGROUP
    33. send_election_dgram: Sending election packet for workgroup WORKGROUP on subnet 192.168.178.50
    34. send_election_dgram: Sending election packet for workgroup WORKGROUP on subnet 192.168.178.50
    35. send_election_dgram: Sending election packet for workgroup WORKGROUP on subnet 192.168.178.50
    36. become_domain_master_stage1: Becoming domain master browser for workgroup WORKGROUP on subnet 192.168.178.50
    37. send_election_dgram: Sending election packet for workgroup WORKGROUP on subnet 192.168.178.50
    38. send_election_dgram: Sending election packet for workgroup WORKGROUP on subnet 192.168.178.50
    39. run_elections: >>> Won election for workgroup WORKGROUP on subnet 192.168.178.50 <<<
    40. become_local_master_browser: Starting to become a master browser for workgroup WORKGROUP on subnet 192.168.178.50
    41. *****
    42. Samba server GEPARD is now a domain master browser for workgroup WORKGROUP on subnet 192.168.178.50
    43. *****
    44. *****
    45. Samba name server GEPARD is now a local master browser for workgroup WORKGROUP on subnet 192.168.178.50
    46. *****
    47. announce_local_master_browser_to_domain_master_browser:
    48. We are both a domain and a local master browser for workgroup WORKGROUP. Do not announce to ourselves.
    49. sync_with_dmb:
    50. Initiating sync with domain master browser GEPARD<20> at IP 192.168.178.50 for workgroup WORKGROUP
    Alles anzeigen
    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 :)

    Für den Inhalt des Beitrages 127848 haftet ausdrücklich der jeweilige Autor: letsfindaway

  • Ich würde Samba einfach neu einrichten (vorher "/etc/samba/smb.conf" sichern).
    Oder du probierst Folgendes:

    /etc/systemd/system.conf

    Ist:
    # DefaultTimeoutStopSec=90s

    Soll:
    DefaultTimeoutStopSec=10s

    Einfach mal testen...

    systemd-system.conf(5) — manpages-de — Debian testing — Debian Manpages
    Zitat Albert Einstein:
    "Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit,
    aber bei dem Universum bin ich mir noch nicht ganz sicher."

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

  • sterun schrieb:

    Ich würde Samba einfach neu einrichten
    Damit warte ich noch. Mein Verdacht liegt momentan eher auf systemd als auf Samba.


    sterun schrieb:

    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...


    sterun schrieb:

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von letsfindaway ()

    Für den Inhalt des Beitrages 127909 haftet ausdrücklich der jeweilige Autor: letsfindaway