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

Re: Not stopping daemons, where are we?

"Marvin Renich" <mrvn@renich.org> wrote in message [🔎] 20080702173033.GE10858@flik.wdw">news:[🔎] 20080702173033.GE10858@flik.wdw...
* 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

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).

Well, sending SIGTERM should not cause software to die abruptly, and IIRC sending SIGTERM to all processes happens before sending SIGKILL.

Reply to: