On Wed, Jul 02, 2008 at 02:27:44AM +0200, Bernd Eckenfels wrote:
> 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.

Please explain why these third parties are doing something so braindead as
to rely on the VPN connection only ever disappearing gracefully.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

In article <20080702004858.GA25623@dario.dodds.net> you wrote:
> Please explain why these third parties are doing something so braindead as
> to rely on the VPN connection only ever disappearing gracefully.

I am not talking about the third party, it could be an internal VPN, and yes
it is braindead, welcome to the real world.

Gruss
Bernd


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* 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
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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

"Marvin Renich" <mrvn@renich.org> wrote in message
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

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


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




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Jul 2, 2008 at 8:30 PM, Marvin Renich <mrvn@renich.org> wrote:
> * 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
> 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?
We can add even more flexibility: You may leave today's scripts as they are, and
add "skippable" flag somewhere around LSB headers or /etc/default/<name>.
Then if system administrator will have some weired situation where he
should like
to perform explicit shutdown for particular service - it can just
unset "skippable" flag
for that service.

This will also ease transition - if some service is not explicitly
marked as "skippable", then its
not skippable, i.e. you surely do not harm init scripts that are not
up to date yet.

>
> ...Marvin
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>



--
Zaar


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, Jul 02, 2008 at 04:36:56PM -0400, Joe Smith wrote:

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

The point is that this new proposal applies only to services whose
maintainers decide they do *not* need graceful handling. If you have
another process that does need a graceful shutdown, it's only ever been
guaranteed if you give that process a shutdown script with the right
sequence number, and *all* such shutdown scripts are run *before* the
killall5 is sent.

If something depends on a particular /other/ service to be shut down
gracefully, and this hasn't been coordinated with the package providing the
service, then that something is broken by design. Shooting it in the head
is a feature.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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.

Gruss
Bernd


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

* Bernd Eckenfels <ecki@lina.inka.de> [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.
>
> Gruss
> Bernd
>

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.

...Marvin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[Marvin Renich]
> If the package does need to save state, don't enable the "quick halt"
> option! The maintainer definitely ought to know this.

Why are all of you talking as though sending SIGTERM were not the
standard way to tell a process to save its state and exit gracefully?
It's certainly the method I would use if I were writing a program that
needed to do things at exit time. I thought everyone did it that way.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

On Sat, Jul 05, 2008 at 01:36:43AM -0500, Peter Samuelson wrote:

> [Marvin Renich]
> > If the package does need to save state, don't enable the "quick halt"
> > option! The maintainer definitely ought to know this.

> Why are all of you talking as though sending SIGTERM were not the
> standard way to tell a process to save its state and exit gracefully?
> It's certainly the method I would use if I were writing a program that
> needed to do things at exit time. I thought everyone did it that way.

The question is whether anyone *waits* for the process, to make sure it's
allowed to finish saving state before reaching the end of the runlevel. If
the process is only shut down using sendsigs, there's no guarantee that the
SIGKILL won't arrive before it's done saving state.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org