[Samba] Option configure

[Carlos A. P. Cunha]

Hello!

What is the purpose of the option
*
**--with-**systemd**
****Enable****systemd****integration*

To configure Samba (build).

[Reindl Harald]

What is different afterwards when using with/without? Does it create a
systemd service file?

Do not know about '--with-systemd', but there are no (horrible) systemd
components if you use '--without-systemd'

there is nothing horrible in a systemd service-unit

horrible are large and complex shell scripts trying to do all sort of
magic for start a service and with no clue about service states, no
proper restart-otpions and no proper security options

[***@srv-rhsoft:~]$ cat /etc/systemd/system/smb.service
[Unit]
Description=Samba SMB Daemon

[Service]
Type=forking
LimitNOFILE=32768
ExecStart=/usr/sbin/smbd -D
ExecReload=/usr/bin/kill -HUP $MAINPID
Restart=always
RestartSec=1
Nice=19
PrivateTmp=yes
PrivateDevices=yes
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE
CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK CAP_SYS_CHROOT
SystemCallFilter=~acct modify_ldt add_key adjtimex clock_adjtime
delete_module fanotify_init finit_module get_mempolicy init_module
io_destroy io_getevents iopl ioperm io_setup io_submit io_cancel kcmp
kexec_load keyctl lookup_dcookie mbind migrate_pages mount move_pages
open_by_handle_at perf_event_open pivot_root process_vm_readv
process_vm_writev ptrace remap_file_pages request_key set_mempolicy
swapoff swapon umount2 uselib vmsplice
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib
ReadWriteDirectories=/var/lib/samba

[Carlos A. P. Cunha]

Hello! Thanks for the information , I ask myself this question , why use
Samba 4 with system Systemd , but have not used this option and at first
it's all ok , I was in doubt with her on, would have some benefit .
Thank you

Post by Reindl Harald

What is different afterwards when using with/without? Does it create a
systemd service file?

Do not know about '--with-systemd', but there are no (horrible) systemd
components if you use '--without-systemd'

there is nothing horrible in a systemd service-unit

You have your opinion and I have mine and my opinion (for what it is
worth) is that systemd is something that is looking for a problem that
doesn't really exist and then fixing the problem in a totally insane
way. If systemd was just another init system and was easy to change
then I wouldn't mind, but it keeps gobbling up things that have
nothing to do with an init system and is becoming extremely hard to
remove.
As far as I am concerned, this ends this conversation, you have my
opinion and nothing will change it, so don't bother trying.
Rowland

[Nico Kadel-Garcia]

Post by Reindl Harald

What is different afterwards when using with/without? Does it create a
systemd service file?

Do not know about '--with-systemd', but there are no (horrible) systemd
components if you use '--without-systemd'

there is nothing horrible in a systemd service-unit

Except the horrible systemd logging, instead of flat text rsyslog, and
the extraordinary difficulty of starting any of the daemons inside a
usable debugger.

Post by Reindl Harald
horrible are large and complex shell scripts trying to do all sort of magic
for start a service and with no clue about service states, no proper
restart-otpions and no proper security options

I agree that the shell scripts have often been frighteningly bad for
many daemons. The problem has been solved with many, much lighter
weight and safer init processes, and it integration for Samba makes
Samba development less cross-platform compatible, since systemd *only*
runs on Linux and cannot be integrated to other operating systems due
to its kernel dependencies. My personal favorite has become
daemontools, for which I publish SRPM's, but I don't see that
replacing SysV init or systemd despite its gracefulness, stability,
and maturity.

Systemd has some useful features, especially logging boot-time kernel
operations, but it still has *enormous* procedural and architectural
problems. Binary logging instead of long-established plain text syslog
style logs, unclear and unintuitive layout, insistent restarting of
failed daemons, and the resulting overwriting of crash dumps from
failed daemons as a result are all issues. The replacement of
/etc/resolv.conf with an unstable symlink into its internal DHCP
server, with no feature or plan to have a feature to reset the symlink
if broken by accidenal user test editing with or manipulation by a
configuraiton management system add to the destabilization and
directly impinges Samba based DNS.

Do not get me *started* on the recent systemd default
"UserKillProcess" setting that terminates, silently and with no log
whastoever any dangling user process that belongs to a user whose
shell session has anded. This breaks screen, tmux, nohup'ed or
otherwise backgrounded processes, including long-running hand-starteed
Samba backups or database repair processes for which the active tty
has ended. It's *nasty*.

[Reindl Harald]

Post by Nico Kadel-Garcia
I agree that the shell scripts have often been frighteningly bad for
many daemons. The problem has been solved with many, much lighter
weight and safer init processes, and it integration for Samba makes
Samba development less cross-platform compatible, since systemd *only*
runs on Linux and cannot be integrated to other operating systems due
to its kernel dependencies.

how does that make development less cross-platform compatible?

sorry but that is nonsense since you have to take care of special
handling on other unix types too or just hope that it works there when
no testing machines are available (see recent AIX topics and that nobody
knows by lack of testing machines)

integration with systemd watchdogs is just anotehr small piece of code
to make monitoring relieable in case a service didn't crash but no
longer works and makes things less complx since you can replace
additional monitoring tools

Post by Nico Kadel-Garcia
My personal favorite has become
daemontools, for which I publish SRPM's, but I don't see that
replacing SysV init or systemd despite its gracefulness, stability,
and maturity.

daemontools is a workaround for a broken init system which has no
concept of what happend after fire up a service

Post by Nico Kadel-Garcia
Systemd has some useful features, especially logging boot-time kernel
operations, but it still has *enormous* procedural and architectural
problems. Binary logging instead of long-established plain text syslog
style logs

a complete non-issue since journald (the part which takes care of early
boot logging) don't need to wrote logs to disk as i does not on any of
my machines which all use the rsyslog

$WorkDirectory /var/lib/rsyslog
$IMJournalStateFile imjournal.state

Post by Nico Kadel-Garcia
unclear and unintuitive layout

wrong, you just refuse to trying to understand it for many years

Post by Nico Kadel-Garcia
insistent restarting of failed daemons, and the resulting overwriting
of crash dumps from failed daemons as a result are all issues

nonsense - besides that it's not default this are your friends

StartLimitIntervalSec=
StartLimitBurst=
StartLimitAction=

Post by Nico Kadel-Garcia
The replacement of
/etc/resolv.conf with an unstable symlink into its internal DHCP
server, with no feature or plan to have a feature to reset the symlink
if broken by accidenal user test editing with or manipulation by a
configuraiton management system add to the destabilization and
directly impinges Samba based DNS.

nonsense - that parts are completly optional to use

Post by Nico Kadel-Garcia
Do not get me *started* on the recent systemd default
"UserKillProcess" setting that terminates, silently and with no log
whastoever any dangling user process that belongs to a user whose
shell session has anded. This breaks screen, tmux, nohup'ed or
otherwise backgrounded processes, including long-running hand-starteed
Samba backups or database repair processes for which the active tty
has ended. It's *nasty*

to make it short - i often don't agree with systemd developers, also in
this case but when a default *option* where adjust it to your needs
takes less to write than your whole paragraph about it i can't take it
serious

[mathias dufresne]

Hello,

Post by Carlos A. P. Cunha
What is the purpose of the option
*
**--with-**systemd**
****Enable****systemd****integration*
To configure Samba (build).

[removed troll]

Carlos, it's a good question. I really never recognized this option.
What is different afterwards when using with/without? Does it create
a
systemd service file?

It just means we link to a small library that helps systemd know that
we started up successfully, as I understand it.
This is needed because of the way we double-fork() at startup, so the
original PID values from the process that called exec() is not the long
-term PID.

Andrew,

I expect the --with-systemd is to add the little piece of code which makes
Samba systemd unit files to work correctly, for systemd stop killing
processes after some timeout because it doesn't received the right message
from Samba.

I ask because we are using last Samba and systemd (in version 219 today on
Centos7), we are using shipped systemd unit files (or at least I expect
that's Samba which create them, not the .spec / rpmbuild tool) and service
samba-ad works well when samba-smbd, samba-nmdb and samba-winbindd are all
three killed by systemd after timeout.
Of course Samba works well, running these daemons just calling their names
is sufficient for the service starts well.

I did add --with-systemd to our .spec, compiled a 4.4.5, tested it as file
server and same issue: systemd refuses to understand these processes are
working and kill after some time.

Checking logs of that compilation I get:
...
Checking for
libsystemd-daemon
: not found
Checking for library
systemd-daemon
: no
Checking for library
systemd-libs
: no
Checking for
libsystemd-journal
: not found
Checking for library
systemd-journal
: no
Checking for library
systemd
: no
...

when
rpm -qa systemd*
systemd-libs-219-19.el7_2.9.x86_64
systemd-219-19.el7_2.9.x86_64
systemd-sysv-219-19.el7_2.9.x86_64
systemd-python-219-19.el7_2.9.x86_64

It looks to me that configure script can't find Centos 7 systemd
installation files. Any idea of what I would have missed?

Cheers,

mathias

[martin]

This post might be inappropriate. Click to display it.

[mathias dufresne]

\o/

Martin, thank you very much : )

Our unit files were configured with "Type=forking". I just changed that to
replace it by "Type=notify" and these unit files are starting all three
daemons (nmbd, smbd, winbindd) without killing them after some time.

I did tried that change in our unit files on others servers, with older
Samba version compiled without --with-systemd and changing type to notify
was also enough on these systems.

I expect the issue raised because our deployment script should push these
unit files rather than using those build during packaging (perhaps they are
built only when using --with-systemd, not tested yet).

Thank you all for that : )

Post by mathias dufresne

Post by mathias dufresne
I expect the --with-systemd is to add the little piece of code which

makes

Post by mathias dufresne
Samba systemd unit files to work correctly, for systemd stop killing
processes after some timeout because it doesn't received the right

message

Post by mathias dufresne
from Samba.

Hi Mathias,
A while back we built a test system to try the 4.3 and later packages
"./configure --without-ad-dc --with-systemd --disable-cups
--libdir=/usr/lib64 --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--with-piddir=/var/run --with-sockets-dir=/run --enable-fhs"
After the package build we had a few .service files - I guess as a
result of the --with-systemd switch.
[Unit]
Description=Samba NMB Daemon
After=syslog.target network.target
[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/nmbd.pid
EnvironmentFile=-/etc/sysconfig/samba
ExecStart=/usr/sbin/nmbd $NMBDOPTIONS
ExecReload=/usr/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
We then replaced the current .service files on the system with the ones
from the compiled package. However doing
systemctl restart nmb smb winbind
would cause each service to start and then die after a little while.
Increasing the verbosity just showed the process getting a SIGHUP.
Looking into systemd it seemed to think the process did not start at all.
After some poking around the web [1] we took the original systemd files
that ship with CentOS 7.2 and changed the .service files for nmb, smb
Type=forking
While leaving the rest of the content of the file as is. This has
resolved the issue with service control using systemd.
I hope that might give you an idea of what your problem may be.
Regards,
Martin
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html

[Sonic]

Post by mathias dufresne
It looks to me that configure script can't find Centos 7 systemd
installation files. Any idea of what I would have missed?

Same issues with Debian Jessie - nothing you missed. Apparently
libsystemd-daemon and libsystemd-journal are deprecated and merged
into a single libsystemd file (must have happened some time ago since
Debian has the change). It appears that Samba does not check for
libsystemd (only libsystemd-daemon and libsystemd-journal) during the
config phase so unless one is running some ancient version of systemd
the "--with-systemd" configure option may be quite useless.

Chris

[mathias dufresne]

Post by Sonic
It appears that Samba does not check for
libsystemd (only libsystemd-daemon and libsystemd-journal) during the
config phase so unless one is running some ancient version of systemd
the "--with-systemd" configure option may be quite useless.

Might be wrong on this, see the ../lib/util/wscript_configure script
in the src. It looks like it may search for libsystemd after
libsystemd-daemon and libsystemd-journal, but in my case it doesn't
find that either, possibly as I'm building in a container.
Chris

I did that same search earlier this day, think some time about the issue
came from that but as changing unit file was sufficient on our Centos7 for
all running Samba version (4.4.3, 4.4.4 and 4.4.5) when only last version
was compiled with --with-systemd swtich, I would say that's not the issue.

Chris, can you check into your unit file what kind of type is used?

[Sonic]

Post by mathias dufresne
Chris, can you check into your unit file what kind of type is used?

Mine use Type=forking, I had some issues with Type=notify but it's
been some time so I can't remember what they were. Although one is
that a "systemctl start samba" command did not return a prompt, had to
Ctrl-C out.

[mathias dufresne]

Certainly the behaviour of couple Samba / Systemd has changed at one
moment: I did not write by myself these unit files so the presence of
"type=forking" was wrote by someone else and certainly it was working at
that moment with that kind of type in unit file.

Could you simply try to modify type=forking to type=notify and test again?
Perhaps your old has disappeared (they do sometimes, not often enough)...

Post by Sonic

Post by mathias dufresne
Chris, can you check into your unit file what kind of type is used?

Mine use Type=forking, I had some issues with Type=notify but it's
been some time so I can't remember what they were. Although one is
that a "systemctl start samba" command did not return a prompt, had to
Ctrl-C out.

[Sonic]

Post by mathias dufresne
Could you simply try to modify type=forking to type=notify and test again?
Perhaps your old has disappeared (they do sometimes, not often enough)...

Seems to work for starting smbd and nmbd (although Type=forking has
been running flawlessly for many months) on my Gentoo system.

In my Debian LXC (Debian host) running a Samba AD, besides having to
Ctrl-C to get a prompt back samba dies in short order. Runs fine with
Type=forking.

Chris

[Sonic]

Post by Sonic
samba dies in short order.

-- Logs begin at Tue 2016-07-12 10:42:26 EDT, end at Tue 2016-07-12
11:02:17 EDT. --
Jul 12 11:02:17 kwad samba[310]: Exiting pid 310 on SIGTERM
Jul 12 11:02:17 kwad samba[318]: [2016/07/12 11:02:17.501577, 0]
../source4/smbd/server.c:121(sig_term)
Jul 12 11:02:17 kwad samba[318]: Exiting pid 318 on SIGTERM
Jul 12 11:02:17 kwad samba[319]: [2016/07/12 11:02:17.501617, 0]
../source4/smbd/server.c:121(sig_term)
Jul 12 11:02:17 kwad samba[319]: Exiting pid 319 on SIGTERM
Jul 12 11:02:17 kwad samba[316]: [2016/07/12 11:02:17.501496, 0]
../source4/smbd/server.c:121(sig_term)
Jul 12 11:02:17 kwad samba[316]: Exiting pid 316 on SIGTERM
Jul 12 11:02:17 kwad systemd[1]: samba.service: main process exited,
code=exited, status=127/n/a
Jul 12 11:02:17 kwad systemd[1]: Failed to start Samba AD server.
-- Subject: Unit samba.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit samba.service has failed.
--
-- The result is failed.
Jul 12 11:02:17 kwad systemd[1]: Unit samba.service entered failed state.

[mathias dufresne]

What versions of systemd and samba on your Gentoo and Debian?

Post by mathias dufresne

Post by mathias dufresne
Could you simply try to modify type=forking to type=notify and test

again?

Post by mathias dufresne
Perhaps your old has disappeared (they do sometimes, not often enough)...

Seems to work for starting smbd and nmbd (although Type=forking has
been running flawlessly for many months) on my Gentoo system.
In my Debian LXC (Debian host) running a Samba AD, besides having to
Ctrl-C to get a prompt back samba dies in short order. Runs fine with
Type=forking.
Chris

[Sonic]

Post by mathias dufresne
What versions of systemd and samba on your Gentoo and Debian?

Gentoo runs 230, Debian Jessie runs 215.

[Sonic]

I do get these errors (even when starting with Type=forking):

Jul 12 12:01:36 kwad winbindd[420]: [2016/07/12 12:01:36.491192, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 12:01:36 kwad winbindd[420]: open_internal_pipe: Could not
connect to dssetup pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 12:01:36 kwad winbindd[420]: [2016/07/12 12:01:36.491833, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 12:01:36 kwad winbindd[420]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 12:01:36 kwad winbindd[420]: [2016/07/12 12:01:36.492488, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 12:01:36 kwad winbindd[420]: open_internal_pipe: Could not
connect to dssetup pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 12:01:36 kwad winbindd[420]: [2016/07/12 12:01:36.493365, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 12:01:36 kwad winbindd[420]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 12:01:36 kwad winbindd[420]: [2016/07/12 12:01:36.493853, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 12:01:36 kwad winbindd[420]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL

although winbindd is running. I can eliminate the errors by removing
winbindd from the server services parameter but I think it is supposed
to be running for an AD installation.

Chris

[Sonic]

Post by Sonic
Mine use Type=forking, I had some issues with Type=notify

Further testing seems to verify that either type works for starting
nmbd and smbd, but I need forking for starting samba (AD) as samba
dies shortly after starting it with notify.

From some systemd info:
"If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main daemon process. This is the behavior of traditional UNIX
daemons."
I'm guessing that indeed the samba binary calls fork() as part of its
start-up. Can this be verified? And how about the smbd and nmbd
binaries, do they call fork() during stat-up?

Chris

[Achim Gottinger]

Just backported 4.4.5 from debian sid to jessie. samba.service is masked
there. If running as an fileserver the services are started via
smbd.service,nmbd.service, winbind.service.
There is an samba-ad-dc script which is masked by default.
To get the ad-dc up and running with systemd one has to unmask
samba-ad-dc.service and mask smbd.service,nmbd.service, winbind.service.

This is the samba-ad-dc.service script:

[Unit]

Description=Samba AD Daemon

Documentation=man:samba(8) man:samba(7) man:smb.conf(5)

After=network.target

[Service]

Type=notify

NotifyAccess=all

PIDFile=/run/samba.pid

LimitNOFILE=16384

EnvironmentFile=-/etc/default/samba

ExecStart=/usr/sbin/samba $SAMBAOPTIONS

ExecReload=/bin/kill -HUP $MAINPID

[Install]

WantedBy=multi-user.target

Post by Sonic

Post by Sonic
Mine use Type=forking, I had some issues with Type=notify

Further testing seems to verify that either type works for starting
nmbd and smbd, but I need forking for starting samba (AD) as samba
dies shortly after starting it with notify.
"If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main daemon process. This is the behavior of traditional UNIX
daemons."
I'm guessing that indeed the samba binary calls fork() as part of its
start-up. Can this be verified? And how about the smbd and nmbd
binaries, do they call fork() during stat-up?
Chris

[Sonic]

Pretty similar to my samba.service script:
===================================
[Unit]
Description=Samba AD server
After=network.target

[Service]
Type=forking
PIDFile=/usr/local/samba/var/run/samba.pid
LimitNOFILE=16384
ExecStart=/usr/local/samba/sbin/samba
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target
===================================

However the substitution below fails for me.
-Type=forking
+Type=notify
+NotifyAccess=all

I'm compiling samba-master from source.

Would like to know what your EnvironmentFile contains, maybe that's
needed for Type=notify.

Chris

[Achim Gottinger]

I have no /etc/default/samba file.

If you run an ad-dc use samba-ad-dc.service, if not use the smbd, nmbd
and winbind service files and not the samba.service.

Post by Sonic
===================================
[Unit]
Description=Samba AD server
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/samba/var/run/samba.pid
LimitNOFILE=16384
ExecStart=/usr/local/samba/sbin/samba
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
===================================
However the substitution below fails for me.
-Type=forking
+Type=notify
+NotifyAccess=all
I'm compiling samba-master from source.
Would like to know what your EnvironmentFile contains, maybe that's
needed for Type=notify.
Chris

[Sonic]

Post by Achim Gottinger
I have no /etc/default/samba file.

Suspected that much. It isn't then a neccessary entry in the service file.

Post by Achim Gottinger
If you run an ad-dc use samba-ad-dc.service, if not use the smbd, nmbd and
winbind service files and not the samba.service.

On my standalone file server I just run nmbd.service and smbd.service,
no need for winbind at all.
On my test AD system I've always run the samba.service (my equivalent
of your samba-ad-dc.service file), which starts the sbin/samba binary.
The oddity here is that with Type=notify samba dies shortly after
starting.

Chris

[Achim Gottinger]

Post by Sonic

Post by Achim Gottinger
I have no /etc/default/samba file.

Suspected that much. It isn't then a neccessary entry in the service file.

Post by Achim Gottinger
If you run an ad-dc use samba-ad-dc.service, if not use the smbd, nmbd and
winbind service files and not the samba.service.

On my standalone file server I just run nmbd.service and smbd.service,
no need for winbind at all.
On my test AD system I've always run the samba.service (my equivalent
of your samba-ad-dc.service file), which starts the sbin/samba binary.
The oddity here is that with Type=notify samba dies shortly after
starting.
Chris

Did you mask smbd and nmbd services on your addc server?
Only the samba binary must be started it invokes smbd nmbd (winbindd).

achim~

[Sonic]

Post by Achim Gottinger
Did you mask smbd and nmbd services on your addc server?

I don't have those service files on the AD test system, only wrote the
samba.service file.

Chris

[Achim Gottinger]

Does your PIDFile exist?

systemd should use that if defined and exiting.

https://lists.freedesktop.org/archives/systemd-devel/2013-February/009201.html

Post by Sonic
===================================
[Unit]
Description=Samba AD server
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/samba/var/run/samba.pid
LimitNOFILE=16384
ExecStart=/usr/local/samba/sbin/samba
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
===================================
However the substitution below fails for me.
-Type=forking
+Type=notify
+NotifyAccess=all
I'm compiling samba-master from source.
Would like to know what your EnvironmentFile contains, maybe that's
needed for Type=notify.
Chris

[Sonic]

Post by Achim Gottinger
Does your PIDFile exist?

Yes. Everything works properly as long as I use Type=forking.

Chris

[Achim Gottinger]

Funny current debian service files use a wrong PIDFile path (should be
/var/run/amba/samba.pid).

If I use Type=forking and an wrong PIDFile systemctl start samba must be
CTRL-C'ed.

Type=notify works with or without an proper PIDFile.

Post by Sonic

Post by Achim Gottinger
Does your PIDFile exist?

Yes. Everything works properly as long as I use Type=forking.
Chris

[Reindl Harald]

Post by Achim Gottinger
Funny current debian service files use a wrong PIDFile path (should be
/var/run/amba/samba.pid).
If I use Type=forking and an wrong PIDFile systemctl start samba must be
CTRL-C'ed.
Type=notify works with or without an proper PIDFile.

well, after 5 years of production with systemd all that pidfile stuff is
the root of all evil - get rid of it until you have a very godd reason
and most problems will go away

systemd is damned good in monitor process states and pidfiles where a
dirty workaround for init-systems with no clue about anything

that goes so far that i start mysqld without mysqld_safe, Type=simple
and "--pid-file=/dev/null" to get rid of all sort of troubles when
idiotic processes don't create and remove their pid files at the current
point in time

Post by Achim Gottinger

Post by Sonic

Post by Achim Gottinger
Does your PIDFile exist?

Yes. Everything works properly as long as I use Type=forking

[Achim Gottinger]

Post by Reindl Harald

Post by Achim Gottinger
Funny current debian service files use a wrong PIDFile path (should be
/var/run/amba/samba.pid).
If I use Type=forking and an wrong PIDFile systemctl start samba must be
CTRL-C'ed.
Type=notify works with or without an proper PIDFile.

well, after 5 years of production with systemd all that pidfile stuff
is the root of all evil - get rid of it until you have a very godd
reason and most problems will go away
systemd is damned good in monitor process states and pidfiles where a
dirty workaround for init-systems with no clue about anything
that goes so far that i start mysqld without mysqld_safe, Type=simple
and "--pid-file=/dev/null" to get rid of all sort of troubles when
idiotic processes don't create and remove their pid files at the
current point in time

Thank you for the comment, so i removed the pidfile line from the
service file.

With type=forking it shows (8591 is the pid in /var/run/samba/samba.pid)

systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:46:19 CEST; 2s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Process: 8590 ExecStart=/usr/sbin/samba $SAMBAOPTIONS (code=exited,
status=0/SUCCESS)
Main PID: 8591 (samba)
Status: "winbindd: ready to serve connections..."
CGroup: /system.slice/samba-ad-dc.service
├─8591 /usr/sbin/samba
├─8592 /usr/sbin/samba
├─8593 /usr/sbin/samba
├─8594 /usr/sbin/samba
├─8595 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8596 /usr/sbin/samba
├─8597 /usr/sbin/samba
├─8598 /usr/sbin/samba
├─8599 /usr/sbin/samba
├─8600 /usr/sbin/samba
├─8601 /usr/sbin/samba
├─8602 /usr/sbin/samba
├─8603 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─8604 /usr/sbin/samba
├─8605 /usr/sbin/samba
├─8608 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8609 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8611 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─8613 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground

With

Type=notify
NotifyAccess=all

systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:48:50 CEST; 2s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Main PID: 8749 (samba)
Status: "winbindd: ready to serve connections..."
CGroup: /system.slice/samba-ad-dc.service
├─8749 /usr/sbin/samba
├─8750 /usr/sbin/samba
├─8751 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8752 /usr/sbin/samba
├─8753 /usr/sbin/samba
├─8754 /usr/sbin/samba
├─8755 /usr/sbin/samba
├─8756 /usr/sbin/samba
├─8757 /usr/sbin/samba
├─8758 /usr/sbin/samba
├─8759 /usr/sbin/samba
├─8760 /usr/sbin/samba
├─8761 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─8762 /usr/sbin/samba
├─8763 /usr/sbin/samba
├─8766 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8767 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8769 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─8771 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground

Here it does not mention the inital process pid. Both options work
without killing the processes.

If i remove NotifyAccess=all

systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:50:50 CEST; 16s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Main PID: 8875 (samba)
Status: "samba: ready to serve connections..."
CGroup: /system.slice/samba-ad-dc.service
├─8875 /usr/sbin/samba
├─8876 /usr/sbin/samba
├─8877 /usr/sbin/samba
├─8878 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8879 /usr/sbin/samba
├─8880 /usr/sbin/samba
├─8881 /usr/sbin/samba
├─8882 /usr/sbin/samba
├─8883 /usr/sbin/samba
├─8884 /usr/sbin/samba
├─8885 /usr/sbin/samba
├─8886 /usr/sbin/samba
├─8887 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─8888 /usr/sbin/samba
├─8889 /usr/sbin/samba
├─8892 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8893 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8895 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─8897 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground

Jul 12 23:50:50 dc3 samba[8875]: [2016/07/12 23:50:50.042455, 0]
../lib/util/become_daemon.c:124(daemon_ready)
Jul 12 23:50:50 dc3 samba[8875]: STATUS=daemon 'samba' finished starting
up and ready to serve connections
Jul 12 23:50:50 dc3 winbindd[8887]: [2016/07/12 23:50:50.173942, 0]
../source3/winbindd/winbindd_cache.c:3245(initialize_winbindd_cache)
Jul 12 23:50:50 dc3 winbindd[8887]: initialize_winbindd_cache: clearing
cache and re-creating with version number 2
Jul 12 23:50:50 dc3 smbd[8878]: [2016/07/12 23:50:50.470873, 0]
../lib/util/become_daemon.c:124(daemon_ready)
Jul 12 23:50:50 dc3 systemd[1]: samba-ad-dc.service: Got notification
message from PID 8878, but reception only permitted for main PID 8875
Jul 12 23:50:50 dc3 smbd[8878]: STATUS=daemon 'smbd' finished starting
up and ready to serve connections
Jul 12 23:50:50 dc3 winbindd[8887]: [2016/07/12 23:50:50.682114, 0]
../lib/util/become_daemon.c:124(daemon_ready)
Jul 12 23:50:50 dc3 systemd[1]: samba-ad-dc.service: Got notification
message from PID 8887, but reception only permitted for main PID 8875
Jul 12 23:50:50 dc3 winbindd[8887]: STATUS=daemon 'winbindd' finished
starting up and ready to serve connections

There are two warnings about messages for smbd and winbindd pids,
otherwise it's working.

Type=simple does not work

● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: deactivating (stop-sigterm) since Tue 2016-07-12 23:53:49
CEST; 11s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Process: 9047 ExecStart=/usr/sbin/samba $SAMBAOPTIONS (code=exited,
status=0/SUCCESS)
Main PID: 9047 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/samba-ad-dc.service
└─9049 /usr/sbin/samba

Jul 12 23:53:49 dc3 systemd[1]: Starting Samba AD Daemon...
Jul 12 23:53:49 dc3 systemd[1]: Started Samba AD Daemon.
Jul 12 23:53:49 dc3 samba[9047]: [2016/07/12 23:53:49.141341, 0]
../source4/smbd/server.c:373(binary_smbd_main)
Jul 12 23:53:49 dc3 samba[9047]: samba version 4.4.5-Debian started.

There is one samba process running and systemctl stop samba does not end
that process. "kill 9049" does the job. The file
/var/run/samba/samba.pid shows an previous used pid.
So I'll use

Type=notify
NotifyAccess=all

and no PIDFile.

Post by Reindl Harald

Post by Achim Gottinger

Post by Sonic

Post by Achim Gottinger
Does your PIDFile exist?

Yes. Everything works properly as long as I use Type=forking

[Sonic]

Post by Achim Gottinger
With type=forking it shows (8591 is the pid in /var/run/samba/samba.pid)
systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon

I get this:
=================================================================
# systemctl status samba.service
● samba.service - Samba AD server
Loaded: loaded (/etc/systemd/system/samba.service; enabled)
Active: active (running) since Tue 2016-07-12 14:39:17 EDT; 4h 44min ago
Process: 21350 ExecStart=/usr/local/samba/sbin/samba (code=exited,
status=0/SUCCESS)
Main PID: 21351 (samba)
CGroup: /system.slice/lxc.service/system.slice/samba.service
├─21351 /usr/local/samba/sbin/samba
├─21352 /usr/local/samba/sbin/samba
├─21354 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─21355 /usr/local/samba/sbin/samba
├─21356 /usr/local/samba/sbin/samba
├─21357 /usr/local/samba/sbin/samba
├─21358 /usr/local/samba/sbin/samba
├─21359 /usr/local/samba/sbin/samba
├─21360 /usr/local/samba/sbin/samba
├─21361 /usr/local/samba/sbin/samba
├─21362 /usr/local/samba/sbin/samba
├─21363 /usr/local/samba/sbin/winbindd -D --option=server
role check:inhibit=yes --foreground
├─21364 /usr/local/samba/sbin/samba
├─21365 /usr/local/samba/sbin/samba
├─21368 /usr/local/samba/sbin/winbindd -D --option=server
role check:inhibit=yes --foreground
├─21369 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─21370 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─21372 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground

Jul 12 19:14:17 kwad winbindd[21368]: [2016/07/12 19:14:17.981972, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:14:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:14:17 kwad winbindd[21368]: [2016/07/12 19:14:17.982073, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:14:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985495, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to dssetup pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985653, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985747, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
=================================================================

Trying to figure out the anomaly with winbindd starting, although it is running.

Chris

[Achim Gottinger]

Post by Sonic

Post by Achim Gottinger
With type=forking it shows (8591 is the pid in /var/run/samba/samba.pid)
systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon

=================================================================
# systemctl status samba.service
● samba.service - Samba AD server
Loaded: loaded (/etc/systemd/system/samba.service; enabled)
Active: active (running) since Tue 2016-07-12 14:39:17 EDT; 4h 44min ago
Process: 21350 ExecStart=/usr/local/samba/sbin/samba (code=exited,
status=0/SUCCESS)
Main PID: 21351 (samba)
CGroup: /system.slice/lxc.service/system.slice/samba.service
├─21351 /usr/local/samba/sbin/samba
├─21352 /usr/local/samba/sbin/samba
├─21354 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─21355 /usr/local/samba/sbin/samba
├─21356 /usr/local/samba/sbin/samba
├─21357 /usr/local/samba/sbin/samba
├─21358 /usr/local/samba/sbin/samba
├─21359 /usr/local/samba/sbin/samba
├─21360 /usr/local/samba/sbin/samba
├─21361 /usr/local/samba/sbin/samba
├─21362 /usr/local/samba/sbin/samba
├─21363 /usr/local/samba/sbin/winbindd -D --option=server
role check:inhibit=yes --foreground
├─21364 /usr/local/samba/sbin/samba
├─21365 /usr/local/samba/sbin/samba
├─21368 /usr/local/samba/sbin/winbindd -D --option=server
role check:inhibit=yes --foreground
├─21369 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─21370 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─21372 /usr/local/samba/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
Jul 12 19:14:17 kwad winbindd[21368]: [2016/07/12 19:14:17.981972, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:14:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:14:17 kwad winbindd[21368]: [2016/07/12 19:14:17.982073, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:14:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985495, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to dssetup pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985653, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
Jul 12 19:19:17 kwad winbindd[21368]: [2016/07/12 19:19:17.985747, 0]
../source3/winbindd/winbindd_cm.c:1849(wb_open_internal_pipe)
Jul 12 19:19:17 kwad winbindd[21368]: open_internal_pipe: Could not
connect to lsarpc pipe: NT_STATUS_UNSUCCESSFUL
=================================================================
Trying to figure out the anomaly with winbindd starting, although it is running.
Chris

It doesn not show
Status: "winbindd: ready to serve connections..."
below the Mai PID line.
I guess samba still tries to start winbindd and if you start it in
type=notify mode it did not send the sd_notify started message.
That is why it does not return after systemctl start samba, it has not
finished the starting process.
Once you fixed the winbind problem I assume it will work with type=notify.

[Reindl Harald]

Post by martin
With
Type=notify
NotifyAccess=all
systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:48:50 CEST; 2s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Main PID: 8749 (samba)
Status: "winbindd: ready to serve connections..."
CGroup: /system.slice/samba-ad-dc.service
├─8749 /usr/sbin/samba
├─8750 /usr/sbin/samba
├─8751 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8752 /usr/sbin/samba
├─8753 /usr/sbin/samba
├─8754 /usr/sbin/samba
├─8755 /usr/sbin/samba
├─8756 /usr/sbin/samba
├─8757 /usr/sbin/samba
├─8758 /usr/sbin/samba
├─8759 /usr/sbin/samba
├─8760 /usr/sbin/samba
├─8761 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─8762 /usr/sbin/samba
├─8763 /usr/sbin/samba
├─8766 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8767 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8769 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─8771 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
Here it does not mention the inital process pid

Main PID: 8749 (samba)

[Achim Gottinger]

Post by Achim Gottinger

Post by martin
With
Type=notify
NotifyAccess=all
systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:48:50 CEST; 2s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Main PID: 8749 (samba)
Status: "winbindd: ready to serve connections..."
CGroup: /system.slice/samba-ad-dc.service
├─8749 /usr/sbin/samba
├─8750 /usr/sbin/samba
├─8751 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8752 /usr/sbin/samba
├─8753 /usr/sbin/samba
├─8754 /usr/sbin/samba
├─8755 /usr/sbin/samba
├─8756 /usr/sbin/samba
├─8757 /usr/sbin/samba
├─8758 /usr/sbin/samba
├─8759 /usr/sbin/samba
├─8760 /usr/sbin/samba
├─8761 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─8762 /usr/sbin/samba
├─8763 /usr/sbin/samba
├─8766 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8767 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─8769 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─8771 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
Here it does not mention the inital process pid

Main PID: 8749 (samba)

Was talking about "Process 8590" whom invokes 8591 and exitst afterwards.
This one is only listed on forked mode status.


systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: active (running) since Tue 2016-07-12 23:46:19 CEST; 2s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Process: 8590 ExecStart=/usr/sbin/samba $SAMBAOPTIONS (code=exited,
status=0/SUCCESS)
Main PID: 8591 (samba)

[Reindl Harald]

Post by Achim Gottinger

Post by Achim Gottinger
Main PID: 8749 (samba)

Was talking about "Process 8590" whom invokes 8591 and exitst afterwards.
This one is only listed on forked mode status

what else do you expect than not forked mode?
the only interesting for systemd is the main-pid in any mode

http://stackoverflow.com/questions/10932592/why-fork-twice
http://code.activestate.com/recipes/66012-fork-a-daemon-process-on-unix/

[Achim Gottinger]

Under some circumstances for debugging purposes it may be helfpfull to
know the PID used during startup as well. Just noted that this one is
only listen in forked mode.
Samba does fork with type=notify as well but systemd is waiting for
sd_notify message in that mode.

Anyway, for curiosity i recompiled samba with --without-systemd.

If i use type=notify mode now and no PIDFile, systemctl start
samba-ad-dc does not start samba but it shows the starte PID. There is
an leftover samba process running whom can be killed with -9.

***@dc1:/srv/packages/jessie# systemctl status samba-ad-dc
● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: inactive (dead) since Wed 2016-07-13 17:44:08 CEST; 30s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Process: 11641 ExecStart=/usr/sbin/samba $SAMBAOPTIONS (code=exited,
status=0/SUCCESS)
Main PID: 11641 (code=exited, status=0/SUCCESS)

With an proper PIDFile line, samba starts but systemctl start
samba-ad-dc must be CTRL-C'ed. No starter PID is shown. Samba itself works.

● samba-ad-dc.service - Samba AD Daemon
Loaded: loaded (/lib/systemd/system/samba-ad-dc.service; enabled)
Active: activating (start) since Wed 2016-07-13 17:46:05 CEST; 1min
25s ago
Docs: man:samba(8)
man:samba(7)
man:smb.conf(5)
Main PID: 11812 (samba)
CGroup: /system.slice/samba-ad-dc.service
├─11812 /usr/sbin/samba
├─11813 /usr/sbin/samba
├─11814 /usr/sbin/samba
├─11815 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─11816 /usr/sbin/samba
├─11817 /usr/sbin/samba
├─11818 /usr/sbin/samba
├─11819 /usr/sbin/samba
├─11820 /usr/sbin/samba
├─11821 /usr/sbin/samba
├─11822 /usr/sbin/samba
├─11823 /usr/sbin/samba
├─11824 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground
├─11825 /usr/sbin/samba
├─11826 /usr/sbin/samba
├─11829 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─11830 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
├─11832 /usr/sbin/smbd -D --option=server role
check:inhibit=yes --foreground
└─11834 /usr/sbin/winbindd -D --option=server role
check:inhibit=yes --foreground

Forked mode works like it did with --with-systemd.

So if samba(-ad-dc).service does not start with type=notify, it must be
build with --with-systemd.
If system-ctl start samba(-ad-dc) must be killed with CTRL-D can be
caused by type=forked and wrong PIDFile or by type=notify with the
correct PIDFile but no systemd support compiled in. :-)

Post by Reindl Harald

Post by Achim Gottinger

Post by Achim Gottinger
Main PID: 8749 (samba)

Was talking about "Process 8590" whom invokes 8591 and exitst
afterwards.
This one is only listed on forked mode status

what else do you expect than not forked mode?
the only interesting for systemd is the main-pid in any mode
http://stackoverflow.com/questions/10932592/why-fork-twice
http://code.activestate.com/recipes/66012-fork-a-daemon-process-on-unix/

[Sonic]

If indeed it generally works either way, that is with Type=fork and
Type=notify is one actually preferable than the other?

As I posted earlier - systemd says:
"If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main daemon process. This is the behavior of traditional UNIX
daemons."

Does the above actually occur with the nmbd, smbd, and samba binaries?
IOW, do they act, in this sense, like traditional UNIX daemons? If so,
maybe Type=fork is the preferred method, if not, maybe Type=notify
should be used.

Chris

[Achim Gottinger]

Post by Sonic
If indeed it generally works either way, that is with Type=fork and
Type=notify is one actually preferable than the other?
"If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main daemon process. This is the behavior of traditional UNIX
daemons."
Does the above actually occur with the nmbd, smbd, and samba binaries?
IOW, do they act, in this sense, like traditional UNIX daemons? If so,
maybe Type=fork is the preferred method, if not, maybe Type=notify
should be used.
Chris

The advantage of the notify mode is that the samba binary decides if it
has succesfully started. It depends on working systemd-notify
environment and builtin systemd support in samba.

Found an older bug reports about systemd-notify and lxc.
https://lists.freedesktop.org/archives/systemd-bugs/2014-March/002416.html

[Achim Gottinger]

Post by Achim Gottinger
Just backported 4.4.5 from debian sid to jessie. samba.service is
masked there. If running as an fileserver the services are started
via smbd.service,nmbd.service, winbind.service.
There is an samba-ad-dc script which is masked by default.
To get the ad-dc up and running with systemd one has to unmask
samba-ad-dc.service and mask smbd.service,nmbd.service, winbind.service.
[Unit]
Description=Samba AD Daemon
Documentation=man:samba(8) man:samba(7) man:smb.conf(5)
After=network.target
[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/samba.pid
LimitNOFILE=16384
EnvironmentFile=-/etc/default/samba
ExecStart=/usr/sbin/samba $SAMBAOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target

that is basically what init scripts do, i.e if fileserver start the
nmbd, smbd and winbindd binaries, if AD DC just start the samba
binary, but is this what Sonic is doing ?
Rowland

He mentioned using systemctl start samba.
I can not run this here becuase it is masked an no samba.service file
exists in the backport.
This is intentional on debian see here.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769714
With LSB init scripts the samba script started smbd,nmbd and samba-ad-dc
scripts. These checked smb.conf for the addc role and decided themselfes
if they must start or not.
Updating debian from backported 4.4.3 to backported 4.4.5 was abit messy
(thank you systemd). Had to comment out the server role line on my
addc's and stop samba. After the update i had to reenable to server role
line and mask unmask services as described earlier.


These are the other service files from 4.4.5+dfsg-2

smbd.service
[Unit]
Description=Samba SMB Daemon
Documentation=man:smbd(8) man:samba(7) man:smb.conf(5)
After=network.target nmb.service winbind.service

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/smbd.pid
LimitNOFILE=16384
EnvironmentFile=-/etc/default/samba
ExecStart=/usr/sbin/smbd $SMBDOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

nmbd.service
[Unit]
Description=Samba NMB Daemon
Documentation=man:nmbd(8) man:samba(7) man:smb.conf(5)
After=network.target

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/nmbd.pid
EnvironmentFile=-/etc/default/samba
ExecStart=/usr/sbin/nmbd $NMBDOPTIONS
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

winbind.service
[Unit]
Description=Samba Winbind Daemon
Documentation=man:winbindd(8) man:samba(7) man:smb.conf(5)
After=network.target nmb.service

[Service]
Type=notify
NotifyAccess=all
PIDFile=/run/winbindd.pid
EnvironmentFile=-/etc/default/samba
ExecStart=/usr/sbin/winbindd "$WINBINDOPTIONS"
ExecReload=/bin/kill -HUP $MAINPID
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

[Sonic]

if AD DC just start the samba binary, but is this what Sonic is doing ?

Indeed it is what I'm doing, I recently posted my samba.service file
in this thread.

Chris

[Sonic]

Are starting the 'smbd', 'nmbd' and samba binaries together ?

I have "After=network.target nmbd.service" in my smbd.service file so
nmbd will always start first. This is on my desktop system which is
just a file sever "security = user". It appears that either type,
forking or notify works fine on this system, although forking has been
used successfully for many months.

On a test system running an AD (server role = active directory domain
controller) samba dies shortly after starting if I use Type=notify,
only Type=forking is successful at keeping it running.

Another strange oddity, referencing the page @
https://wiki.samba.org/index.php/Changing_the_DNS_backend#Changing_from_Samba_Internal_DNS_to_BIND_DLZ
it appears that using that the "dns" entry in "server services" ,
either plain or prepended with a + or - has some bearing on whether or
not one is using the internal DNS or BIND_DLZ. As I provisioned with
BIND_DLZ I run fine with "dns" left out of the "server services" parm,
but attempting to use "-dns" prevents samba from running properly -
not all of the services start (winbondd for one) and it dies soon
after starting. I'm wondering if that page is in error or if "-dns" is
only valid if at one time previously samba was running with the
internal DNS.

Thanks,

Chris

[Sonic]

server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd,
ntp_signd, kcc, dnsupdate

Yes, that's what I have. Just found it odd that adding -dns would
cause such problems.

Chris

[Steve Litt]

On Tue, 12 Jul 2016 14:53:39 -0400

Post by Sonic

Post by Sonic
Mine use Type=forking, I had some issues with Type=notify

Further testing seems to verify that either type works for starting
nmbd and smbd, but I need forking for starting samba (AD) as samba
dies shortly after starting it with notify.
"If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main daemon process. This is the behavior of traditional UNIX
daemons."
I'm guessing that indeed the samba binary calls fork() as part of its
start-up. Can this be verified? And how about the smbd and nmbd
binaries, do they call fork() during stat-up?
Chris

Hi Chris,

I don't use systemd, but what I recommend to my systemd friends when
they run into this sort of problem is to start up daemontools-encore
from systemd, and start up Samba (using the -F for foreground) from
daemontools-encore. That way you get the benefit of systemd (there must
be SOME benefit or you'd be using Runit, OpenRC or sysvinit), yet you
have the easily examined startup and supervision of daemontools-encore.

Everything I just said about daemontools-encore can also be said of
both Runit and S6.

HTH,

SteveT

Steve Litt
July 2016 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques

[Achim Gottinger]

Post by Sonic

Post by mathias dufresne
It looks to me that configure script can't find Centos 7 systemd
installation files. Any idea of what I would have missed?

Same issues with Debian Jessie - nothing you missed. Apparently
libsystemd-daemon and libsystemd-journal are deprecated and merged
into a single libsystemd file (must have happened some time ago since
Debian has the change). It appears that Samba does not check for
libsystemd (only libsystemd-daemon and libsystemd-journal) during the
config phase so unless one is running some ancient version of systemd
the "--with-systemd" configure option may be quite useless.
Chris

You also need the libsystemd-dev if you build samba manual.

[Sonic]

Post by Achim Gottinger
You also need the libsystemd-dev if you build samba manual.

Indeed, the crux of the biscuit. This is why Type=notify did not work
for me. So used to Gentoo where you always have the source. With these
binary based distros the dev packages can be overlooked. And now
examining the config.log I see that samba finds systemd.
Thanks!

[Achim Gottinger]

Post by Sonic

Post by Achim Gottinger
You also need the libsystemd-dev if you build samba manual.

Indeed, the crux of the biscuit. This is why Type=notify did not work
for me. So used to Gentoo where you always have the source. With these
binary based distros the dev packages can be overlooked. And now
examining the config.log I see that samba finds systemd.
Thanks!

Glad it works and systemd-notify works with lxc.
The systemd development package is not mentioned as an requirementi n
the wiki
https://wiki.samba.org/index.php/Operating_system_requirements/Dependencies_-_Libraries_and_programs#Debian_.2F_Ubuntu

achim~