Control: reassign -1 snmpd Control: forcemerge 611668 -1 [ Sending through NNNN-submitter@b.d.o because your mail server rejected my initial reply… ]
On Sun, 2013-08-04 at 19:56:38 +0200, Guillem Jover wrote: > Hi! > > On Sun, 2013-08-04 at 16:28:15 +0100, Glen Pitt-Pladdy wrote: > > Package: dpkg > > Version: 1.16.10 > > Severity: normal > > > I noticed services not starting at boot and failed to start when manually > > started via init scripts. On further investigation this appears S-S-D > > interacts badly with LXC containers. > > > > To illistrate, when a daemon is running in an LXC container, S-S-D > > believes it is already running on the host, hence when refuses to > > start them. For example, manually executing (with --verbose) the > > same as happens in the snmpd init script: > > It believes so, because it's told to match only on the exec name, > which it does and finds and operates on every and each instance of > the executable found on the system. The init script should be more > specific to avoid this kind of issue. > > > # start-stop-daemon --verbose --start --oknodo --exec /usr/sbin/snmpd \ > > -- -LS n d -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid > > /usr/sbin/snmpd already running. > > Notice how the pid file is only passed to the daemon (after --), but > not to s-s-d. > > > While this may not affect a large proportion of users, it risks > > crippling the host system if critical services start on a container > > before the host at boot. > > So, this is really not a problem with s-s-d, but with the specific > init script. If that script is part of Debian, then we should reassign > the bug report, otherwise if it's a local init script you'd need to > fix that and I'd just close the bug report. This problem exists in Debian, and has already been filed before, reassigning. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
