FS#9030 - daemons are not stopped in pre_remove()

Attached to Project: Arch Linux
Opened by Corrado Primier (bardo) - Friday, 28 December 2007, 11:25 GMT
Last edited by Dan McGee (toofishes) - Saturday, 09 February 2008, 14:54 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Damir Perisa (damir.perisa)
Aaron Griffin (phrakture)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


When removing a package containing a daemon, the related daemon should be stopped, but this almost never happens. The only packages that do not show this problem are firebird, freeradius, smbnetfs and partimage, which are all in [community]. The consequences are a running daemon that can be stopped only by killing it manually and a stale file in /var/run/daemons.

I can't think of an easy solution for this problem, not even talking of a nice one, the only two options I have in my mind are:
1. Define a guideline for packages containing a daemon and enforce it for the next builds (long and painful road).
2. Find some way to do it automatically. Since this is distro-specific it shouldn't be taken care of by pacman, but maybe there's a way to add distro-specific hooks support to pacman, so that when it finds a file owned by the package in /etc/rc.d it tries to stop the daemon before removing the package.
This task depends upon

Closed by  Dan McGee (toofishes)
Saturday, 09 February 2008, 14:54 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Pacman is a package manager, not a daemon manager. See the comments for reasoning.
Comment by Aaron Griffin (phrakture) - Tuesday, 08 January 2008, 07:51 GMT
I don't actually think this is a bug. Saying "the daemon should be stopped" isn't rationale enough to prove it. Sure apt does it that way, but we do a lot of things differently than apt does.

This, however, is just my opinion. I'll bring it up with the devs, but were it me, I'd simply say this would be hand-holding.
Comment by Damir Perisa (damir.perisa) - Tuesday, 08 January 2008, 08:23 GMT
having a daemon still running while it is uninstalled can have strange effects. from this logic, i'm for implementing the shutdown of a daemon before removing it from the system. or has it any disadvantages to stop it while removing its files from the system?
Comment by Jeff Mickey (codemac) - Tuesday, 08 January 2008, 08:53 GMT
I agree with Aaron that this is hand holding.

What next, removing it from /etc/rc.conf DAEMONS array as well? We are merely removing the software package, not reconfiguring your system for you.
Comment by Roman Kyrylych (Romashka) - Tuesday, 08 January 2008, 09:07 GMT
Well, while I think stopping a daemon before removal is a good thing, but I don't think it's pacman's (.install scriptlet's) job.
If user wants to remove a package - I guess he/she should stop using it before this (which includes stopping the daemon).
Or are we talking about upgrade here as well?
Comment by Aaron Griffin (phrakture) - Tuesday, 08 January 2008, 09:16 GMT
My point exactly, Roman. If the user wishes the daemon stopped, they can stop it themselves.

@Damir: There are no disadvantages beyond complexity. What this report is basically asking is to add a /etc/rc.d/foo stop call to the pre_remove of *every* package which contains and rc.d script. It's quite an undertaking.
Comment by Karolina Lindqvist (karolinali) - Tuesday, 08 January 2008, 10:10 GMT
I thought it already was like this. What purpose can it possibly fulfill to have a daemon running when the package is removed? It can crash, with strange error messages, or do other undefined things since its needed files are missing. The system can get into a stage where things get seriously screwed up. It can even be a security hole, since some daemons run with root privilege.

The demon in etc/rc.conf is just ignored, at boot time, and that is no harm.
What problem is there to add /etc/rc.d/foo stop call to the pre_remove of *every* package which contains and rc.d script? That is easy. Alternatives is to make the remove fail, if the daemon is running, but that is harder.

Archlinux is already annoying in hindering you from doing reasonable things in some cases, so I think it fits the profile to hinder you to do possible serious and damaging things from doing something unreasonable that might not be easy to recover from or forsee the consequences of.

It can be done in pacman, which requires no changes in the daemon packages. If a script is removed from /etc/rc.d, the stop entrypoint is automatically called. Or the more annoying way, give a question - Have you really stopped the running daemon?

Note that pacman have options for removing packages recursively, or when something it depends on is removed, and a daemon can get removed that way, even unintentionally. It might even be that someone else did the system setup for you, and you don't know all the running daemons, or have forgotten it. So without this "feature" you have to manually analyse every single -R command, to see if somehow a running daemon gets removed. The same things happens when a daemons gets upgraded with pacman -Su. Then it has to be stopped, since the old version might just not like the new version's files. Or should it be done the microsoft way, to force a reboot efter reinstalling anything, just to be sure?
Comment by Damir Perisa (damir.perisa) - Tuesday, 08 January 2008, 10:18 GMT
@Aaron: complexity is not a disadvantage for maintaining correct procedures. it is an undertaking but not a huge one. some daemons shut down not by being killed externally but by calling them with the command to shut down e.g. mpd:
stat_busy "Stopping Music Player Daemon"
/usr/bin/mpd --kill /etc/mpd.conf &> /dev/null
if [ $? -gt 0 ]; then
rm_daemon mpd
and if mpd is removed while running, it can not be shutted down correctly afterwards. (so the process gets killed roughly at shutdown of the machine finally). i realise that this is not right and i will implement correct procedure (shutdown pre_removal) with next release. -> adding me to this bug

@Roman: during update, maintainers of daemons should check if the daemon needs to be restarted or sent a singal to and implement this to their install functions

Comment by Travis Willard (Cerebral) - Tuesday, 08 January 2008, 12:46 GMT
I see and understand both sides of this debate.

On the one hand, it is hand-holding a bit - if the applications in question WEREN'T daemons, this bug would be closed pretty quick, with a message saying "Don't uninstall Firefox while you're still running it, silly!" or whatever app was being discussed.

However, in a way, daemons are designed to 'run and forget' - you stick them in an array in rc.conf then conveniently forget they're running, and everything just works. Calling /etc/rc.d/${daemonname} stop before removing everything is a one-liner fix to any package (two-liner if you decide to check the daemon is actually running first) and it prevents strange and mysterious stuff from happening.

A quick run over core/extra/community/unstable turns up 288 packages that reference /etc/rc.d in their PKGBUILDs - there may be more that have it hidden in 'make install' or something of that sort, but that's a rough number of how many packages across all repos would need to be fixed.
Comment by Roman Kyrylych (Romashka) - Tuesday, 08 January 2008, 12:56 GMT
There's another way of doing this: via pacman hooks. The idea was proposed by Aaron long time ago (what's the status, Aaron?).
It will allow to implement deamon stopping in one place instead of modifying hundreds of packages.
Comment by Aaron Griffin (phrakture) - Tuesday, 08 January 2008, 13:19 GMT
Regarding the issues of upgrades, I'm 95% sure we should NEVER restart the daemons. What if config files need to be merged first? *kaboom* What if this is a webserver and you upgrade apache? *kaboom*

Travis: Thanks for the quick count.

@Karolina: A system can get "screwed up" a lot of ways. Can you show me one daemon that will render a system useless when removed while running? The worst thing that will happen is that you lose data relative to that daemon itself. So, remove exim, and you lose some emails. Remove mpd and your mpd database may be corrupted, etc etc

Here's the thing. I think this is silly. We've been running without anything like this for... what 5 years? Anyone is more than welcome to start modifying 288 packages to stop the daemon on pre_remove, as there's nothing stopping you. Patches welcome.

@Roman: pacman hook status - 0% complete

Comment by Dan McGee (toofishes) - Tuesday, 08 January 2008, 17:11 GMT
Do NOT touch my running daemons. Period. That breaks shit.

I will never signoff on a package that does this.

EDIT: and most daemons I know do not fail if uninstalled. That is a complete farce. This isn't Windows- libraries are loaded into memory and kept until needed, config files are not parsed once a minute, etc.
Comment by eliott (cactus) - Tuesday, 08 January 2008, 17:38 GMT
I agree completely with Dan.
Comment by Corrado Primier (bardo) - Tuesday, 08 January 2008, 18:05 GMT
I am seeing myself that there's a lot of pros and cons for both sides.

@Karolina: so when you run pacman -R you don't want to check what you're removing by dependency? I'm not sure Arch is the distro for you. Also, if a daemon is vital for you, you should put it in HoldPkg, and check upgrades, too.
Finally, remember that pacman is a cross-distro package manager, so if you want this to be done through pacman, then the hooks support must be implemented first, as Roman and me already pointed out, since not every distro will want this to happen, or will have rc scripts in /etc/rc.d.

@Dan, I see your point, and you're right about daemons not breaking. My question is: why would *you* uninstall a daemon without stopping it? I just see one corner case: when pacman is broken and you need to remove the package just to reinstall it a few moments later (think of the right-now-unsupported package substitution), but this is completely another problem, and not enabling daemon stopping *just for this reason* seems stupid to me.

About the stale file, since /var/run gets emptied at every boot (see rc.sysinit), this could be considered a minor problem, since it only lasts until the next reboot. Anyway this is an architectural problem, and an official position should be taken, so the question remains valid.
Comment by Aaron Griffin (phrakture) - Tuesday, 08 January 2008, 18:09 GMT
@bardo: Dan had a very good example of installing dropbear for testing while over ssh... so openssh goes poof, and if the daemon were stopped, one minor connection hiccup and you can no longer access the machine remotely.

I could probably think of a few cases that'd be similar, but I think most of them are oriented at managing servers and machines remotely. If you never do this, it's not a big deal, but once you're talking about remote ONLY access, daemons remaining running until I tell them to stop could be a huge deal
Comment by Corrado Primier (bardo) - Tuesday, 08 January 2008, 18:26 GMT
@Aaron: dropbear/ssh and remote management are a good enough example for me. So I can say it's safe not to stop daemons *by default*, and I won't complain if this doesn't get implemented =)
Comment by héctor (hacosta) - Tuesday, 08 January 2008, 20:34 GMT
i'm not a tu or anything, but as a user all i ask for is consistency, take for instance dependencies in initscripts, some didn't do any dependency solving (apache on network back when network started loopback) yet other initscripts tried to do too much and started other daemons... this leads to inconsistency which sucks... now pacman has never killed processes just because a package is removed, let's keep it that way. A (consistent... as in built into pacman) warning should be _more_ than enough if you determine that some action needs to be taken.
Comment by Glenn Matthys (RedShift) - Thursday, 10 January 2008, 00:25 GMT
As an arch user you should know this yourself. pacman is a package manager, not something that manages the state of the machine.
Comment by Aaron Griffin (phrakture) - Thursday, 10 January 2008, 17:03 GMT
Nicely put RedShift.

So what's the final consensus here? Close with "won't implement"?
Comment by Roman Kyrylych (Romashka) - Thursday, 10 January 2008, 17:13 GMT
"won't implement"++
Comment by eliott (cactus) - Thursday, 10 January 2008, 17:30 GMT
Very nicely said RedShift.

@aaron I think won't implement would be fine.
Comment by Travis Willard (Cerebral) - Thursday, 10 January 2008, 18:21 GMT
> So what's the final consensus here? Close with "won't implement"?
Comment by Allan McRae (Allan) - Saturday, 09 February 2008, 11:05 GMT
Is four enough for a consensus so this can be closed?