Bug 13111 - nmbd starts fine with no interfaces, but doesn't notify systemd that it started
Summary: nmbd starts fine with no interfaces, but doesn't notify systemd that it started
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.6.7
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-30 14:28 UTC by Andreas Hasenack
Modified: 2020-04-10 20:57 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Hasenack 2017-10-30 14:28:33 UTC
nmbd seems to start fine when there are no non-loopback interfaces up, and will loop indefinitely:

        /* We only count IPv4, non-loopback interfaces here. */
        while (iface_count_v4_nl() == 0) {
            sleep(5);
            load_interfaces();
        }

It can happen that during boot there is really no interface available, because, for example, it's a desktop connected via wifi and the wireless connection is only established after the user logs in.

nmbd will happily start up and wait for an interface, but systemd is expecting a notification because the Type is set to notify:
$ cat packaging/systemd/nmb.service 
[Unit]
Description=Samba NMB Daemon
After=syslog.target network.target

[Service]
Type=notify
(...)

So after about 1m30s without a notification from nmbd, systemd will just kill it:

Oct 30 14:25:51 artful-samba-init systemd[1]: nmbd.service: Supervising process 171 which is not our child. We'll most likely not notice when it exits.
...
Oct 30 14:27:21 artful-samba-init systemd[1]: nmbd.service: Start operation timed out. Terminating.
Oct 30 14:27:21 artful-samba-init systemd[1]: nmbd.service: Killing process 171 (nmbd) with signal SIGKILL.
Oct 30 14:27:21 artful-samba-init systemd[1]: nmbd.service: Killing process 171 (nmbd) with signal SIGKILL.
Oct 30 14:27:21 artful-samba-init systemd[1]: Failed to start Samba NMB Daemon.
Oct 30 14:27:21 artful-samba-init systemd[1]: nmbd.service: Unit entered failed state.
Oct 30 14:27:21 artful-samba-init systemd[1]: nmbd.service: Failed with result 'timeout'.
Comment 1 Björn Jacke 2017-11-11 23:21:52 UTC
see https://github.com/samba-team/samba/pull/70 for a proposed solution. Is that one working for you?
Comment 2 Andreas Hasenack 2017-11-13 12:45:35 UTC
I don't know if zero means infinity:

       TimeoutStartSec=
           Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again.
           Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass "infinity" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5)).

But with zero, the systemd job that starts nmbd stays stuck when there is no network:

root@artful-samba-nonet:~# time systemctl start nmbd
(stuck forever?)

nmbd stays running of course, waiting for the network.

During boot, it stays like this:
root@artful-samba-nonet:~# systemctl status nmbd
● nmbd.service - Samba NMB Daemon
   Loaded: loaded (/lib/systemd/system/nmbd.service; enabled; vendor preset: enabled)
   Active: activating (start) since Mon 2017-11-13 12:38:48 UTC; 4min 7s ago
     Docs: man:nmbd(8)
           man:samba(7)
           man:smb.conf(5)
 Main PID: 287 (nmbd)
   Status: "nmbd: No local IPv4 non-loopback interfaces available, waiting for interface ..."
    Tasks: 1 (limit: 4915)
   Memory: 7.0M
      CPU: 39ms
   CGroup: /system.slice/nmbd.service
           └─287 /usr/sbin/nmbd

root@artful-samba-nonet:~# systemd-analyze blame
Bootup is not yet finished. Please try again later.

Until the network comes up, of course.
Comment 3 Mikhail Novosyolov 2020-04-10 16:24:35 UTC
+1 for this, it still happens with samba 4.10
Comment 4 Björn Jacke 2020-04-10 20:57:02 UTC
this was fixed with 0e571054a61e9de69190ae023199d1670e097e88 in Dec. 2017. This bug should have been closed after.

If you have Samba system which does not work, you need to contact the package vendor actually.