Control: reassign -1 samba Control: retitle -1 samba: Uses very lax matching options for start-stop-daemon Control: severity -1 serious Control: found -1 2:4.1.17+dfsg-2+deb8u1 Control: found -1 2:4.3.3+dfsg-1
[ If the severity does not seem right, feel free to downgrade. ] Hi! On Tue, 2016-01-12 at 11:28:19 +0100, Maarten Tromp wrote: > Package: dpkg > Version: 1.18.4 > Severity: normal > On a server with LXC containers (virtual machines), there may be > several copies of the same daemon running. For instance one inside > a container and one on the host machine. This confuses > start-stop-daemon. In my case this happened with samba running on > both my host machine and inside a lxc container. > Start-stop-daemon does not take the containers into account. Using > start-stop-daemon inside a container works fine, but when you try to > start a daemon on the host machine when there already is a daemon > with the same name running inside a container, start-stop-daemon > sees the running daemon and doesn't start a new one. s-s-d only does what it is told, and this behavior is documented in the man page. In this case it seems the samba package is simply not passing more specific matching options, such as at least --exec *and* --pidfile, which means it matches exclusively on the exec name or the pid of any random program in case there's a dangling pidfile, affecting any such instance on the system, inside non-isolated containers, chroots, etc. > The work-around I use is to stop samba inside the container, then > start samba on the host machine, then start samba inside the container. > The bug occurs on a machine running Debian stable, amd64 multiarch > kernel: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 > GNU/Linux > dpkg version: 1.17.26 > lxc version: 1.0.6 This needs to be fixed in samba itself, on stable too as this might cause unintended downtime or loss of service, etc. Reassigning. Thanks, Guillem
