Problem with /sbin/service stop FOO in uninstall scripts...

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

 



Hi folks.

I stumbled across a problem today which at first sight might sound trivial and irrelevant, but i'll come to some examples later.

The problem is that hardly any of the uninstall scripts which have a service they want to stop ever check if the service is running at all.

They usually simply do a:

if [ "$1" = 0 ]; then
    /sbin/service FOO stop >/dev/null 2>&1
    /sbin/chkconfig --del FOO
fi

Thats nice and fine in the general case, but as soon as you are working in a chroot environment you can get really strange results:

Imagine you are remotely logged into a system via ssh, have a chroot and are working in it and decide to remove the package openssh-server in that chroot.

What would you except? Surely not that your sshd on the remote system suddenly stops. But unfortunately thats what then happens because /sbin/service stop calls killproc which first tries to find /var/lock/subsys/FOO, then some other checks and if it didn't find anything in the end it calls pidof FOO. And that just goes through /proc and if it finds a matching name, in that case the sshd of the remote system it happily uses that one to kill. Bang! Your sshd is gone. Imagine that with a system 100s of miles away...

And thats only 1 example, it can hit you with a rescue system as well where you work in a chroot to bring back up your system again.

But there is light at the end of the tunnel: There are several fairly straightforward and pretty nice solutions to that problem.

1) As vixie-cron already does simply do this:

if [ "$1" = 0 ]; then
[ -f /var/lock/subsys/crond ] && /sbin/service crond stop >/dev/null 2>&1
/sbin/chkconfig --del crond
fi


Nice, easy and understandable. Only stop the service if it is running at all. This is actually my favourite solution as it's really clean and doesn't change behaviour of a system command.

2) Fix /sbin/pidof to check wether the /proc/1/root matches the found /proc/$pid/root

This solution would require a fix in pidof. It would also change the current behaviour, but arguably to correct a bug that pidof had. Because honestly i wouldn't expect pidof to list pids of processes outside of my chroot.

3) Fix the inbetweener: killproc() in initrc functions. So basically keep pidof as it is but make the check mentioned in 2) in killproc() instead.

I see that 3rd solution a way around fixing possibly 76 specfiles in devel with solution 1.

Just food for though and comments welcome, as always. I'd really like to hear if you think this is a problem, too, or if i am just paranoid. :)

Read ya, Phil

--
Philipp Knirsch      | Tel.:  +49-711-96437-470
Development          | Fax.:  +49-711-96437-111
Red Hat GmbH         | Email: Phil Knirsch <phil@xxxxxxxxx>
Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
D-70178 Stuttgart
Motd:  You're only jealous cos the little penguins are talking to me.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux