Bug#888743: pidofproc returns PIDs in foreign chroots and containers
AFAICS its documented in start-stop-daemon(8) for "start-stop-daemon -x": "Take into account processes running from inside a chroot will also be matched, so other match restrictions might be needed." Regards Harri
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Hi *, I’ve got an initscript in which I cannot use pidofproc for various reasons so I use start-stop-daemon (in the dpkg package) for this. Does this also affect that? I do not use lxc, container stuff, etc. so I’ve got neither any idea about them nor any way to test this. (If so I will make a clone of the bug and assign that to dpkg.) Thanks, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Works very well. But how comes that this report has been marked as fixed? Its not fixed, it has just been moved out of sight to experimental to avoid a decision. :-( Sorry to say, but other distros are better in fixing bugs. Regards Harri
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
AFAICS these bug reports seem to be related: #742588: stop action of init script on the host system kills nscd daemons in linux containers #858837: lsb-base: pidofproc should limit itself to processes in host system if running on an LXC host #888569: sysv startup script stumbles over smtpd running in a LXC container Probably there are more. Since I replaced "pidof" by "pidof -c" in a private lsb-base package Debian's startup procedure became much more stable in my environment (appr >200 hosts running Jessie and Stretch, systemd and sysvinit). I would suggest to include this change into experimental. Patch is attached. Another option might be to ignore pidof completely and rely upon the services' pidfiles. Regards Harri diff -ur lsb-9.20161125/debian/changelog lsb-9.20161125+nmu1/debian/changelog --- lsb-9.20161125/debian/changelog 2016-11-25 16:15:24.0 +0100 +++ lsb-9.20161125+nmu1/debian/changelog 2018-01-29 14:32:26.0 +0100 @@ -1,3 +1,10 @@ +lsb (9.20161125+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * pidofproc: use "pidof -c" (Closes: #888743) + + -- Harald Dunkel Mon, 29 Jan 2018 14:32:26 +0100 + lsb (9.20161125) unstable; urgency=medium [ Didier Raboud ] diff -ur lsb-9.20161125/init-functions lsb-9.20161125+nmu1/init-functions --- lsb-9.20161125/init-functions 2016-11-25 16:00:10.0 +0100 +++ lsb-9.20161125+nmu1/init-functions 2018-01-29 14:32:26.0 +0100 @@ -107,7 +107,7 @@ # pid file doesn't exist, try to find the pid nevertheless if [ -x /bin/pidof ] && [ ! "$specified" ]; then status="0" - /bin/pidof -o %PPID -x $1 || status="$?" + /bin/pidof -c -o %PPID -x $1 || status="$?" if [ "$status" = 1 ]; then return 3 # program is not running fi
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
It seems that sssd is affected by this problem as well. I lost EMails due to "unknown user" bounces triggered by sssd going away, so I am raising the severity. Regards Harri
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
PS: I highly appreciate your concerns against blindly increasing the list of depndencies. Regards Harri signature.asc Description: OpenPGP digital signature
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Is there a replacement for this package? Regards Harri signature.asc Description: OpenPGP digital signature
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Hi there Harald, Le lundi, 29 janvier 2018, 14.19:53 h CET Harald Dunkel a écrit : > Apparently pidofproc returns the PIDs of programs running > in a chroot or in a container, if there is no local PID file. > This is a *huge* problem for me, because either the init > scripts on the host fail to restart services, or they affect > services running in a container/chroot. > (…) > lsb-base version 9.20170808 has the same problem. I would highly > appreciate a fix for stretch and sid. For all practical concerns, you should consider the LSB package orphaned (and I should probably just go ahead and orphan it). For the bug at hand, I would recommend checking what Ubuntu has in their pidofproc command in lsb-base, but I've long resisted re-using theirs as the list of conditionals is really scary. Any update of src:lsb goes on _all possible Debian machines_, so that didn't leave me with a lot of willingness to change anything there. I'm not opposed to a change there, and I don't challenge the validity of that bug, I'm merely saying that I won't be the one pushing it. Patches and NMUs welcome, but please upload to experimental first! :-) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#888743: pidofproc returns PIDs in foreign chroots and containers
Package: lsb-base Version: 9.20161125 Apparently pidofproc returns the PIDs of programs running in a chroot or in a container, if there is no local PID file. This is a *huge* problem for me, because either the init scripts on the host fail to restart services, or they affect services running in a container/chroot. Sample session: root@mydb01a:~# . /lib/lsb/init-functions root@mydb01a:~# pidofproc /usr/sbin/smtpd 26623 root@mydb01a:~# ps -ef | grep smtp[d] root 1689 1541 0 Jan17 ?00:00:00 /usr/sbin/smtpd uml-net 1690 1689 0 Jan17 ?00:00:00 smtpd: klondike uml-net 1691 1689 0 Jan17 ?00:00:00 smtpd: control uml-net 1692 1689 0 Jan17 ?00:00:00 smtpd: lookup uml-net 1693 1689 0 Jan17 ?00:00:00 smtpd: pony express lxc-dns+ 1694 1689 0 Jan17 ?00:00:00 smtpd: queue uml-net 1695 1689 0 Jan17 ?00:00:00 smtpd: scheduler root 4193 4032 0 Jan10 ?00:00:00 /usr/sbin/smtpd lxc-dns+ 4194 4193 0 Jan10 ?00:00:00 smtpd: klondike lxc-dns+ 4195 4193 0 Jan10 ?00:00:00 smtpd: control lxc-dns+ 4196 4193 0 Jan10 ?00:00:00 smtpd: lookup lxc-dns+ 4197 4193 0 Jan10 ?00:00:00 smtpd: pony express zabbix4198 4193 0 Jan10 ?00:00:00 smtpd: queue lxc-dns+ 4199 4193 0 Jan10 ?00:00:00 smtpd: scheduler root 26623 1 0 14:06 ?00:00:00 /usr/sbin/smtpd opensmt+ 26625 26623 0 14:06 ?00:00:00 smtpd: klondike opensmt+ 26626 26623 0 14:06 ?00:00:00 smtpd: control opensmt+ 26627 26623 0 14:06 ?00:00:00 smtpd: lookup opensmt+ 26628 26623 0 14:06 ?00:00:00 smtpd: pony express opensmt+ 26629 26623 0 14:06 ?00:00:00 smtpd: queue opensmt+ 26630 26623 0 14:06 ?00:00:00 smtpd: scheduler Please note the smtpds running in 2 LXC containers. If I kill the local smtpd, then pidofproc finds the foreign smtpds: root@mydb01a:~# kill 26623 root@mydb01a:~# pidofproc /usr/sbin/smtpd 4199 4198 4197 4196 4195 4194 4193 1695 1694 1693 1692 1691 1690 1689 root@mydb01a:~# echo $? 0 If pidofproc would use "pidof -c" internally, then it should work as expected: root@mydb01a:~# /bin/pidof -o %PPID -x /usr/sbin/smtpd 4199 4198 4197 4196 4195 4194 4193 1695 1694 1693 1692 1691 1690 1689 root@mydb01a:~# /bin/pidof -c -o %PPID -x /usr/sbin/smtpd root@mydb01a:~# echo $? 1 lsb-base version 9.20170808 has the same problem. I would highly appreciate a fix for stretch and sid. Regards Harri
