Re: Not stopping daemons, where are we?
* Bernd Eckenfels <email@example.com> [080703 09:57]:
> In article <[🔎] 20080702173033.GE10858@flik.wdw> you wrote:
> > The Debian maintainer for a specific VPN decides it does not need
> > special shutdown handling
> Nono, thats not my point. My point is, that a maintainer of any package
> cannot easyly forsee which part of the system he is using (resolver, pam,
> proxy, ..) might depend on a daemon - at a specific user's installation.
> The downside might be regular unexpected errors at shutdown like "host not
> found". Those should be catched/ignored, but you never know.
> This might not be a problem (because I also dont have real examples) but,
> then again - its good to talk about it.
If you are saying that the maintainer of SuperVPN, who is trying to
decide whether or not to mark his package as "use killall5 instead of
the initscript when halting", may not know whether certain services used
by the package are provided by daemons that may have already shut down,
my answer is that the maintainer most likely does (and should) know
that, but it is irrelevant.
The relevant question (pertaining to how other packages affect the
"quick halt" option of this package) is, "if services that might be
needed by this package are shut down between the time the sysadmin asks
for a halt and the time this package actually exits, will it adversely
affect user or sysadmin data?" That is, does the package need to save
some data or state to disk (or to another daemon), and are certain
daemons needed for that purpose?
If the package is not trying to save any state, it doesn't matter that
the package normally queries a DNS server that might not respond; the
sysadmin has already said to shut down.
If the package does need to save state, don't enable the "quick halt"
option! The maintainer definitely ought to know this.
A caching DNS server is an example of a daemon that might very well
benefit from the "quick halt" option.