Recently Samba gained systemd integration [1]. systemd and its sd_notify API make the daemonization process unnecessary [2]. I am running Samba 4.1.11 on systemd 208 (openSUSE 13.1) with "-F". Although Samba correctly informs its readiness, it prints a confusing (and wrong because it actually will not fork) error to the log: Sep 06 17:21:48.690317 hostname systemd[1]: Starting Samba SMB Daemon... Sep 06 17:21:48.692114 hostname systemd[1]: About to execute: /usr/share/samba/update-apparmor-samba-profile Sep 06 17:21:48.692751 hostname systemd[1]: Forked /usr/share/samba/update-apparmor-samba-profile as 1569 Sep 06 17:21:48.692977 hostname systemd[1]: smb.service changed dead -> start-pre Sep 06 17:21:48.694292 hostname systemd[1569]: Executing: /usr/share/samba/update-apparmor-samba-profile Sep 06 17:21:48.707049 hostname systemd[1]: Child 1569 belongs to smb.service Sep 06 17:21:48.707062 hostname systemd[1]: smb.service: control process exited, code=exited status=0 Sep 06 17:21:48.707204 hostname systemd[1]: smb.service got final SIGCHLD for state start-pre Sep 06 17:21:48.707683 hostname systemd[1]: About to execute: /usr/sbin/smbd $SMBDOPTIONS Sep 06 17:21:48.708175 hostname systemd[1]: Forked /usr/sbin/smbd as 1572 Sep 06 17:21:48.708456 hostname systemd[1]: smb.service changed start-pre -> start Sep 06 17:21:48.715728 hostname systemd[1572]: Executing: /usr/sbin/smbd -F Sep 06 17:21:48.933465 hostname smbd[1572]: [2014/09/06 17:21:48.933371, 0] ../source3/smbd/server.c:1294(main) Sep 06 17:21:48.933545 hostname smbd[1572]: standard input is not a socket, assuming -D option Sep 06 17:21:49.092412 hostname systemd[1]: Got notification message for unit smb.service Sep 06 17:21:49.092425 hostname systemd[1]: smb.service: Got message Sep 06 17:21:49.092432 hostname systemd[1]: smb.service: got READY=1 Sep 06 17:21:49.092543 hostname systemd[1]: smb.service changed start -> running Sep 06 17:21:49.092553 hostname systemd[1]: Job smb.service/start finished, result=done Sep 06 17:21:49.093665 hostname systemd[1]: Started Samba SMB Daemon. Sep 06 17:21:49.093865 hostname systemd[1]: smb.service: got STATUS=smbd: ready to serve connections... systemd got READY=1. Done. PIDFile= is unnecessary with type=notify + no fork mode. Besides that, systemd deletes the file apparently when PIDFile= is configured: Sep 06 17:35:56.577791 hostname systemd[1]: Trying to enqueue job smb.service/stop/replace Sep 06 17:35:56.577817 hostname systemd[1]: Installed new job smb.service/stop as 273 Sep 06 17:35:56.577841 hostname systemd[1]: Enqueued job smb.service/stop as 273 Sep 06 17:35:56.577906 hostname systemd[1]: Stopping Samba SMB Daemon... Sep 06 17:35:56.578134 hostname systemd[1]: smb.service changed running -> stop-sigterm Sep 06 17:35:56.583487 hostname systemd[1]: Child 1572 belongs to smb.service Sep 06 17:35:56.583524 hostname systemd[1]: smb.service: main process exited, code=killed, status=15/TERM Sep 06 17:35:56.583551 hostname systemd[1]: smb.service changed stop-sigterm -> dead Sep 06 17:35:56.583642 hostname systemd[1]: Job smb.service/stop finished, result=done Sep 06 17:35:56.583665 hostname systemd[1]: Stopped Samba SMB Daemon. Sep 06 17:35:56.581244 hostname smbd[1574]: [2014/09/06 17:35:56.581178, 0] ../lib/util/pidfile.c:153(pidfile_unlink) Sep 06 17:35:56.581362 hostname smbd[1574]: Failed to delete pidfile /run/samba/smbd.pid. Error was No such file or directory Related to http://cgit.freedesktop.org/systemd/systemd/commit/?id=9285c9ff263d90439810735ddca074b4b4193f05 ? [1] https://bugzilla.samba.org/show_bug.cgi?id=10517 [2] http://www.freedesktop.org/software/systemd/man/daemon.html
Oh, I see. I need "-D -F". They are not mutually exclusive... Anyway, when compiled with systemd integration, upstream samba.sysconfig should use "-D -F" by default and PIDFile dropped from the service file to tell downstream folks that non-forking mode is preferable.
One more thing: NotifyAccess=all can be removed too. NotifyAccess is implicitly set to "main" with Type=notify.
One more thing 2: The setsid() call (become_daemon()) is unnecessary. systemd will call it in the forked process before daemon's execution. Add --no-process-group to the list.
The pid file is not created when smbd is not running as daemon: source3/smbd/server.c 1356 if (is_daemon) 1357 pidfile_create(lp_pid_directory(), "smbd"); On the other hand, function exit_server_common (called via smbd_exit_server and smbd_exit_server_cleanly) unconditionally calls pidfile_unlink. This seems wrong to me as the pid file is not even created and therefore it should not make an attempt to delete other files. (found when running Samba 4 via QEMU's -net user,smb option).
OK, so the incorrect pid file unlink has nothing to do with systemd.
Could smbd/nmbd/winbindd use something like this? (excerpt from source3/smbd/server.c) if (!is_daemon && !is_a_socket(0)) { if (!interactive) { DEBUG(3, ("Standard input is not a socket, assuming " #if HAVE_LIBSYSTEMD_DAEMON "-D option. Running under systemd, also assuming -F.\n")); #else "-D option.\n")); #endif /* HAVE_LIBSYSTEMD_DAEMON */ } /* * Setting is_daemon here prevents us from eventually calling * the open_sockets_inetd() */ is_daemon = True; #if HAVE_LIBSYSTEMD_DAEMON Fork = False; #endif /* HAVE_LIBSYSTEMD_DAEMON */ } Then move sd_notifyf call out of do_fork in lib/util/become_daemon.c if (do_fork) { if(fork()) _exit(0); } #if HAVE_LIBSYSTEMD_DAEMON /* No need to pass MAINPID, because we will not fork under systemd */ sd_notifyf(0, "READY=0\nSTATUS=Starting process..."); #endif /* HAVE_LIBSYSTEMD_DAEMON */ And drop from .service files NotifyAccess= (only the main processes use daemon_ready, daemon_status, etc, right?) and PIDFile=.
What do you think about this logic? if (is_daemon && !interactive) { #if HAVE_LIBSYSTEMD_DAEMON /* * sd_booted() does the same check. acess() prevent us from * pulling libsystemd dependency here. */ if (Fork && access("/run/systemd/system/", F_OK) >= 0) { DEBUG(3, ("running under systemd, assuming -F option\n")); Fork = False; } #endif /* HAVE_LIBSYSTEMD_DAEMON */ DEBUG(3, ("Becoming a daemon.\n")); become_daemon(Fork, no_process_group, log_stdout); } I am CCing Alexander who did the systemd integration.
We actually want smbd and winbindd to double fork. systemd supports this mode. Why do you want to inhibit forking in smbd/winbindd?
It is not needed. Just (loosely) trying to follow daemon(7) "New-Style Daemons" section. The needless fork(), for example, confuses systemd (until the parent exits) sometimes: "Supervising process XXX which is not our child. We'll most likely not notice when it exits."
*** This bug has been marked as a duplicate of bug 13129 ***