* Bernd Eckenfels <[EMAIL PROTECTED]> [080701 20:45]: > In article <[EMAIL PROTECTED]> 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 sequence. 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 thread? ...Marvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
