Arch Linux

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.

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?

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.

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?

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.

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?

@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
stat_fail
else
rm_daemon mpd
stat_done
fi
;;
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

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.

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.

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

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.

I agree completely with Dan.

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.

@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

@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 =)

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.

As an arch user you should know this yourself. pacman is a package manager, not something that manages the state of the machine.

Nicely put RedShift.

So what's the final consensus here? Close with "won't implement"?

"won't implement"++

yeah.
Very nicely said RedShift.

@aaron I think won't implement would be fine.

> So what's the final consensus here? Close with "won't implement"?
+1

Is four enough for a consensus so this can be closed?