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.
  • Stopping NMB time out

    Hallo zusammen,

    das ist zwar kein Startproblem, sondern ein Stopp-Problem, aber ich poste es trotzdem mal in dieser Gruppe. So etwa gefühlt jedes 10te Mal braucht mein Rechner beim Runterfahren über 90 Sekunden. Jetzt konnte ich mal den Schuldigen identifizieren, die Ursache kenne ich noch nicht:

    Quellcode

    1. gepard:~ # journalctl --boot=-1
    2. Dec 27 20:55:11 gepard systemd[1]: Stopping LVM2 metadata daemon...
    3. Dec 27 20:55:11 gepard systemd[1]: Stopping Samba NMB Daemon...
    4. Dec 27 20:55:11 gepard nmbd[1635]: [2018/12/27 20:55:11.905732, 0] ../source3/nmbd/asyncdns.c:158(start_async_dns)
    5. Dec 27 20:55:11 gepard nmbd[1635]: started asyncdns process 2619
    6. Dec 27 20:55:11 gepard systemd[1]: Removed slice system-getty.slice.
    7. Dec 27 20:55:11 gepard systemd[1]: Stopped LVM2 metadata daemon.
    8. Dec 27 20:55:11 gepard systemd[1694]: Stopped Accessibility services bus.
    9. Dec 27 20:55:11 gepard systemd[1694]: Stopped target Basic System.
    10. Dec 27 20:55:11 gepard systemd[1694]: Stopped target Paths.
    11. Dec 27 20:55:11 gepard systemd[1694]: Stopped target Sockets.
    12. ...
    13. Dec 27 20:55:13 gepard systemd[1]: Stopped Login and scanning of iSCSI devices.
    14. Dec 27 20:55:13 gepard systemd[1]: Stopped Login Service.
    15. Dec 27 20:55:13 gepard systemd[1]: Stopped target User and Group Name Lookups.
    16. Dec 27 20:55:13 gepard systemd[1]: Stopping Name Service Cache Daemon...
    17. Dec 27 20:55:13 gepard systemd[1]: Stopped Name Service Cache Daemon.
    18. Dec 27 20:56:41 gepard systemd[1]: nmb.service: State 'stop-sigterm' timed out. Killing.
    19. Dec 27 20:56:41 gepard systemd[1]: nmb.service: Killing process 1635 (nmbd) with signal SIGKILL.
    20. Dec 27 20:56:41 gepard systemd[1]: nmb.service: Killing process 2619 (nmbd) with signal SIGKILL.
    21. Dec 27 20:56:41 gepard systemd[1]: nmb.service: Main process exited, code=killed, status=9/KILL
    22. Dec 27 20:56:41 gepard systemd[1]: Stopped Samba NMB Daemon.
    23. Dec 27 20:56:41 gepard systemd[1]: nmb.service: Unit entered failed state.
    24. Dec 27 20:56:41 gepard systemd[1]: nmb.service: Failed with result 'timeout'.
    25. Dec 27 20:56:41 gepard systemd[1]: Stopped target Network.
    26. Dec 27 20:56:41 gepard systemd[1]: Stopping wicked managed network interfaces...
    27. Dec 27 20:56:41 gepard wickedd-dhcp4[974]: eth0: Request to release DHCPv4 lease with UUID 122c255c-472d-0b00-fe03-000004000000: releasing...
    28. Dec 27 20:56:42 gepard wicked[2647]: eth0 device-ready
    29. Dec 27 20:56:42 gepard systemd[1]: Stopped wicked managed network interfaces.
    30. Dec 27 20:56:42 gepard systemd[1]: Stopping wicked network nanny service...
    31. Dec 27 20:56:42 gepard systemd[1]: Stopped target Network (Pre).
    Alles anzeigen

    Das sind zwei Ausschnitte aus dem letzten Bootvorgang. Bei 20:55:11 wird der NMB Daemon gestoppt. 90 Sekunden später wird erkannt, dass das nicht funktioniert hat und der NMB Service wird dann per kill gestoppt.

    Die Frage ist jetzt natürlich, warum sich NMB nicht vorher schon beendet hat. Wo kann ich hier nach weiteren Indizien schauen?

    Ach ja, und meine Pflichtangaben:

    • openSUSE Leap 15.0
    • aktueller Stand
    • Desktop-Rechner nur LAN, kein WLAN, deshalb wicked


    Quellcode

    1. family@gepard:~> uname -a
    2. Linux gepard 4.12.14-lp150.12.28-default #1 SMP Mon Dec 3 16:46:15 UTC 2018 (b91289f) x86_64 x86_64 x86_64 GNU/Linux

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von letsfindaway () aus folgendem Grund: Ergänzungen

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

  • Kann es sein, dass ich solchen Fällen noch eine Ressource von einem anderen (oder sogar vom lokalen) Rechner aus geöffnet ist?
    Das ist der NetBIOS Nameservice für M$ Netzwerke.
    Ist dein Samba irgendwie mit DNS oder gar ADs verzahnt?

    Du kannst den auch im Interaktiven- oder im Debug- Modus laufen lassen; mag sein, dass das Erhellendes bringt.
    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 127744 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Quellcode

    1. gepard:~ # systemctl status nmb.service
    2. ● nmb.service - Samba NMB Daemon
    3. Loaded: loaded (/usr/lib/systemd/system/nmb.service; enabled; vendor preset: disabled)
    4. Active: active (running) since Fri 2018-12-28 11:52:47 CET; 3min 43s ago
    5. Main PID: 1616 (nmbd)
    6. Status: "nmbd: ready to serve connections..."
    7. Tasks: 2 (limit: 4915)
    8. CGroup: /system.slice/nmb.service
    9. ├─1616 /usr/sbin/nmbd --foreground --no-process-group
    10. └─1642 /usr/sbin/nmbd --foreground --no-process-group
    11. Dec 28 11:53:10 gepard nmbd[1616]: [2018/12/28 11:53:10.214559, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
    12. Dec 28 11:53:10 gepard nmbd[1616]: *****
    13. Dec 28 11:53:10 gepard nmbd[1616]:
    14. Dec 28 11:53:10 gepard nmbd[1616]: Samba name server GEPARD is now a local master browser for workgroup WORKGROUP on subnet 192.168.178.50
    15. Dec 28 11:53:10 gepard nmbd[1616]:
    16. Dec 28 11:53:10 gepard nmbd[1616]: *****
    17. Dec 28 11:53:10 gepard nmbd[1616]: [2018/12/28 11:53:10.214734, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
    18. Dec 28 11:53:10 gepard nmbd[1616]: find_domain_master_name_query_fail:
    19. Dec 28 11:53:10 gepard nmbd[1616]: Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
    20. Dec 28 11:53:10 gepard nmbd[1616]: Unable to sync browse lists in this workgroup.
    Alles anzeigen

    Berichtigung schrieb:

    Kann es sein, dass ich solchen Fällen noch eine Ressource von einem anderen (oder sogar vom lokalen) Rechner aus geöffnet ist?
    Zum fraglichen Zeitpunkt war ich der einzige Teilnehmer im LAN.

    Berichtigung schrieb:

    Ist dein Samba irgendwie mit DNS oder gar ADs verzahnt?
    Nein. Kein Windows im Netz und auch kein lokales DNS.


    Berichtigung schrieb:


    Du kannst den auch im Interaktiven- oder im Debug- Modus laufen lassen; mag sein, dass das Erhellendes bringt.
    Hab jetzt mal log level = 2 in die smb.conf mit aufgenommen und schaue mal, ob ich beim nächsten Hänger hier mehr Informationen finde.

    Danke mal soweit für eure Tipps!

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

  • Sauerland schrieb:

    Poste:

    Quellcode

    1. cat /etc/samba/smb.conf

    Quellcode

    1. gepard:~ # cat /etc/samba/smb.conf
    2. # smb.conf is the main Samba configuration file. You find a full commented
    3. # version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
    4. # samba-doc package is installed.
    5. [global]
    6. workgroup = WORKGROUP
    7. passdb backend = tdbsam
    8. printing = cups
    9. printcap name = cups
    10. printcap cache time = 750
    11. cups options = raw
    12. map to guest = Bad User
    13. logon path = \\%L\profiles\.msprofile
    14. logon home = \\%L\%U\.9xprofile
    15. logon drive = P:
    16. usershare allow guests = Yes
    17. wins support = Yes
    18. usershare max shares = 100
    19. log level = 4
    20. [homes]
    21. comment = Home Directories
    22. valid users = %S, %D%w%S
    23. browseable = No
    24. read only = No
    25. inherit acls = Yes
    26. [profiles]
    27. comment = Network Profiles Service
    28. path = %H
    29. read only = No
    30. store dos attributes = Yes
    31. create mask = 0600
    32. directory mask = 0700
    33. [users]
    34. comment = All users
    35. path = /home
    36. read only = No
    37. inherit acls = Yes
    38. veto files = /aquota.user/groups/shares/
    39. [groups]
    40. comment = All groups
    41. path = /home/groups
    42. read only = No
    43. inherit acls = Yes
    44. [printers]
    45. comment = All Printers
    46. path = /var/tmp
    47. printable = Yes
    48. create mask = 0600
    49. browseable = No
    50. [print$]
    51. comment = Printer Drivers
    52. path = /var/lib/samba/drivers
    53. write list = @ntadmin root
    54. force group = ntadmin
    55. create mask = 0664
    56. directory mask = 0775
    57. guest ok = No
    58. [DriveD]
    59. comment = Drive D
    60. inherit acls = Yes
    61. path = /windows/d
    62. read only = No
    63. [DVD Laufwerk]
    64. inherit acls = Yes
    65. path = /run/media/family/
    66. read only = No
    67. guest ok = Yes
    68. nt acl support = No
    Alles anzeigen

    Habe jetzt den Log Level noch auf 4 hochgezogen. Der zusätzliche Output bei 2 hielt sich noch sehr in Grenzen.

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

  • Hmm, der zusätzliche Log kommt wohl nicht im Journal an, wie ich gedacht hatte, sondern in /var/log/samba/log.nmbd. Auch wieder was gelernt. Da kann ich nun Gut- und Schlechtfälle vergleichen.

    Ein Gutfall (von Start bis Ende):

    Quellcode

    1. [2018/12/27 17:29:18.219730, 0] ../source3/nmbd/asyncdns.c:158(start_async_dns)
    2. started asyncdns process 1694
    3. [2018/12/27 17:29:18.227932, 0] ../lib/util/become_daemon.c:124(daemon_ready)
    4. STATUS=daemon 'nmbd' finished starting up and ready to serve connections
    5. [2018/12/27 17:29:41.261217, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
    6. *****
    7. Samba name server GEPARD is now a local master browser for workgroup WORKGROUP on subnet 192.168.178.50
    8. *****
    9. [2018/12/27 17:29:41.261378, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
    10. find_domain_master_name_query_fail:
    11. Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
    12. Unable to sync browse lists in this workgroup.
    13. [2018/12/27 17:44:58.265531, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
    14. find_domain_master_name_query_fail:
    15. Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
    16. Unable to sync browse lists in this workgroup.
    17. [2018/12/27 17:45:32.898879, 0] ../source3/nmbd/nmbd.c:58(terminate)
    18. Got SIGTERM: going down...
    Alles anzeigen

    Ein Schlechtfall (Hänger):

    Quellcode

    1. [2018/12/27 20:46:30.020785, 0] ../source3/nmbd/asyncdns.c:158(start_async_dns)
    2. started asyncdns process 1660
    3. [2018/12/27 20:46:30.025599, 0] ../lib/util/become_daemon.c:124(daemon_ready)
    4. STATUS=daemon 'nmbd' finished starting up and ready to serve connections
    5. [2018/12/27 20:46:53.058279, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
    6. *****
    7. Samba name server GEPARD is now a local master browser for workgroup WORKGROUP on subnet 192.168.178.50
    8. *****
    9. [2018/12/27 20:46:53.058460, 0] ../source3/nmbd/nmbd_browsesync.c:354(find_domain_master_name_query_fail)
    10. find_domain_master_name_query_fail:
    11. Unable to find the Domain Master Browser name WORKGROUP<1b> for the workgroup WORKGROUP.
    12. Unable to sync browse lists in this workgroup.
    13. [2018/12/27 20:55:11.905732, 0] ../source3/nmbd/asyncdns.c:158(start_async_dns)
    14. started asyncdns process 2619
    Alles anzeigen
    Statt des erwarteten "terminate" hier also ein zweites "start_async_dns". Und in der Tat finde ich dieses Muster in den älteren Logs immer wieder. Ob das genau die Hänger waren, kann ich nicht beweisen, das fehlende "Terminate" und die Häufigkeit sprechen aber sehr dafür.

    Was ist dieser asyncdns Prozess?

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

  • asyncdns ist ASYNChronesDomainNameSystem (-Abfragen).
    Da machen DNS Anfragen dauern können, lassen z.B. Chromium gleich 8 solche Worker laufen, damit auch wenn eine Anfrage länger dauert (und somit "hängt"), der Netzwerk-Stack weiterwursteln kann.
    Ich würde mal die komplette Namesauflösung checken. Insbesondere auf dem Sambaserver.

    Mag sein, dass irgendwas solche dann hängenden Anfragen triggert. Also Anfragen von oder aus dem Netz auf deine Shares, oder ähnliches.
    (Reine Spekulation)
    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 127768 haftet ausdrücklich der jeweilige Autor: Berichtigung