[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#271302: init.d script should not kill other unrelated apache processes



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).

> (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.

> 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".

> 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?

Fabio

-- 
<user> fajita: step one
<fajita> Whatever the problem, step one is always to look in the error log.
<user> fajita: step two
<fajita> When in danger or in doubt, step two is to scream and shout.



Reply to: