Bug#271302: init.d script should not kill other unrelated apache processes
On Sun, Sep 12, 2004 at 05:51:22PM +0200, Fabio Massimo Di Nitto wrote:
> On Sun, 12 Sep 2004, Jeroen van Wolffelaar wrote:
>
> > Package: apache
> > Version: 1.3.31-6
> >
> > While upgrading apache in a chroot, I noticed that:
> >
> > (a) there are two lines trying to stop apache, and not one:
> >
> > Preparing to replace apache 1.3.31-3 (using .../apache_1.3.31-6_i386.deb) ...
> > Stopping web server: apache.
> > Stopping web server: apacheNo process in pidfile `/var/run/apache.pid' found
> > running; none killed.
> > .
> >
> > This might be a different issue, and fwiw, I don't consider the mere fact that
> > two lines are displayed a bug worth reporting.
>
> Yes they both come from maintainer scripts. unfortunatly there is a nasty
> problem upgrading from woody and apparently apache doesn't get kill as it
> should. We had to force this is a really hard way to avoid problems later
> on. like the reload at the first logrotate (there were other bugs related
> to woody->sid upgrade that you can find in the BTS).
I already somehow assumed there was a good reason for it :)
> > (b) It killed the apache process that was running on the main system in addition
> > to the one in the chroot. The init.d script should _not_ touch random
> > processes called 'apache', but only those that are part of the apache package.
>
> The init script doesn't do that.
Indeed, preinst or prerm did that, my fault.
> > The prerm kills all `pidof apache`, it could at least use `pidof
> > /usr/bin/apache to limit it to processes that are Debian's apache (this will
> > not fix killing of apache in other/parent chroot's, but is still better).
> >
>
> I will take this as a wishlist but if you notice from a ps ax the process
> is only "apache".
ps ax on my sarge system, the sid chroot, and a woody system gives lots
of results like:
16096 ? S 0:00 /usr/sbin/apache
And indeed, /proc/16096/cmdline contains /usr/sbin/apache. I guess you
made a typo trying this out.
Also, 'pidof /usr/sbin/apache' works for me (though it still gives both
the main apache and the one in the chroot, but at least it doesn't
contain my $HOME/bin/apache 'daemon' I'm running for testing purposes).
> > In order to really fix killing of processes in different chroots, you could
> > check whether /proc/$PID/exe is a symlink to '/usr/bin/apache' (and doesn't
> > give an error). For chroots that are below the root of the current process,
> > that will give /chroot/usr/bin/apache (for example), and for roots that are
> > upwards of the current root, it will give a permission denied.
>
> hmmm i wasn't aware of this bits. can you work out a patch?
#!/bin/bash
for pid in /proc/[1-9]*; do
exe="`readlink $pid/exe`" || continue
if [ "$exe" = /usr/sbin/apache ] || \
[ "$exe" = "/usr/sbin/apache (deleted)" ]; then
pid=${pid#/proc/}
echo "Apache process I want to kill: $pid"
fi
done
or if you do a 'cd /proc' first, you can do a "for pid in [1-9]*" and
don't need that substitution of which I'm not sure it isn't a bashism.
Maybe that substitution isn't a bashism, and then it doesn't matter. A
third possibility is looping over `pidof /usr/sbin/apache`, such that
the forloop only goes over those processes that have a cmdline starting
with "/usr/sbin/apache\0".
Tested succesfully on my system, both in the chroot and on the main
system, it only gives the pids of apache processes belonging to them,
and neither give the pid of my $HOME/bin/apache process. It's also 'set
-e' safe, and finds those occurances of /usr/sbin/apache processes where
the binary was already deleted. Of course, just like pidof, this isn't
race-safe, as during the killing, new apache childs might have been
created. If you do two runs of this, with a second pause, that should
kill all, since the main process must have died during the first run,
and so no new childs should be created during the second killing spree.
Note that unlike pidof, this script only works as root, since
/proc/$PID/exe is a symlink only follow-able by root and the owner of
the process.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: