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

Re: Not stopping daemons, where are we?

* Bernd Eckenfels <ecki@lina.inka.de> [080701 20:45]:
> In article <[🔎] 20080701223517.GB2670@dario.dodds.net> you wrote:
> >> I mean the pending-write case is the most obvious. But what about resolver
> >> caches, VPNs and the like?
> > 
> > What kind of data loss do you expect to arise from shutting down a VPN
> > client without giving it time to save state?
> I dont expect any data loss - hopefully protocols are not that
> optimistic/broken. But with unclean shutdown you can affect external parties
> with unexected errors. Like resolver problems, user not found and similiar
> problems.

Either I don't understand the usage scenario you are talking about, or I
misunderstand what is being proposed in this thread, or you
misunderstand what is being proposed in this thread.  Here is a more
concrete example of a situation based on what I think is being proposed:

The Debian maintainer for a specific VPN decides it does not need
special shutdown handling, so he marks it to not require calling
"/etc/init.d/SuperVPN stop" when doing a shutdown or reboot.  This is
what I understand this thread is about.  This will result in SuperVPN
not being stopped until the final "kill all remaining processes" step of
the halt or reboot (i.e. don't waste time shutting this daemon down
cleanly, let it die abruptly just before halting).

Now, some other unrelated app, possibly a Debian-provided package and
possibly one installed manually by the sysadmin, uses this VPN and needs
it to be running during the app's normal shutdown (done using the
traditional /etc/init.d/* script) to avoid data loss.  The sysadmin or
Debian maintainer will know that a clean shutdown is required, so will
not mark this init script as "skippable" during the normal shutdown

When the system shuts down, since this other app is not explicitly
marked as "safe to kill without init script during system shutdown", its
init script gets called as usual during shutdown.  At this point, the
VPN is still up, because the "kill all processes" only happens _after_
all init scripts have been called for running daemons.

What is the problem you think might occur with the proposal from this


Reply to: