Re: Not stopping daemons, where are we? - Debian

This is a discussion on Re: Not stopping daemons, where are we? - Debian ; On Tue, 2008-07-01 at 14:42 +0200, Bernd Eckenfels wrote: > In article you wrote: > > As I understand it, there is nothing magic about the approach taken, it > > just doesn't install the symlinks for rc0.d and rc6.d, ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: Re: Not stopping daemons, where are we?

  1. Re: Not stopping daemons, where are we?

    On Tue, 2008-07-01 at 14:42 +0200, Bernd Eckenfels wrote:
    > In article <1214912655.6931.45.camel@flash> you wrote:
    > > As I understand it, there is nothing magic about the approach taken, it
    > > just doesn't install the symlinks for rc0.d and rc6.d, and expects that
    > > the process will be cleaned up. It also reflects this in the LSB
    > > headers, so systems which use that information should also do the same
    > > thing.

    >
    > This is all fine, but what about daemons which have dependencies on remote
    > filesystems without declaration? Apache comes to mind, which often may run
    > on a Network filesystem. If killing all processes at the shutdown does not
    > observe the priority/ordering of the daemons this might kill the filesystem
    > thread before apache can write out pending data.


    There is no such proposal to do this for all daemons. That's why the
    defaults have not changed and the individual packages must do it.

    Quoting https://wiki.ubuntu.com/Teardown which I referenced in my
    previous mail:

    Apache: Performs a controlled shut down of the running Apache web
    server. While a web server is normally not likely to have unflushed
    writes, modules such as mod_perl, mod_python and PHP might; so it's
    important that we do allow a controlled shutdown.


    Thanks,

    James


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

  2. Re: Not stopping daemons, where are we?

    In article <1214917547.6931.48.camel@flash> you wrote:
    > There is no such proposal to do this for all daemons. That's why the
    > defaults have not changed and the individual packages must do it.


    Yes, but do you think individual packages can decide how the environment
    they are running in might look like? I mean the pending-write case is the
    most obvious. But what about resolver caches, VPNs and the like?

    Gruss
    Bernd


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

  3. Re: Not stopping daemons, where are we?

    On Tue, Jul 01, 2008 at 03:38:20PM +0200, Bernd Eckenfels wrote:
    > In article <1214917547.6931.48.camel@flash> you wrote:
    > > There is no such proposal to do this for all daemons. That's why the
    > > defaults have not changed and the individual packages must do it.


    > Yes, but do you think individual packages can decide how the environment
    > they are running in might look like?


    .... yes? Isn't that what a package maintainer is for?

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

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

  4. Re: Not stopping daemons, where are we?

    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.

    Gruss
    Bernd


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

  5. Re: Not stopping daemons, where are we?

    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

  6. Re: Not stopping daemons, where are we?

    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

  7. Re: Not stopping daemons, where are we?

    * Bernd Eckenfels [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

  8. Re: Not stopping daemons, where are we?


    "Marvin Renich" wrote in message
    news:20080702173033.GE10858@flik.wdw...
    >* Bernd Eckenfels [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

  9. Re: Not stopping daemons, where are we?

    On Wed, Jul 2, 2008 at 8:30 PM, Marvin Renich wrote:
    > * Bernd Eckenfels [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/.
    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

  10. Re: Not stopping daemons, where are we?

    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

  11. Re: Not stopping daemons, where are we?

    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

  12. Re: Not stopping daemons, where are we?

    * Bernd Eckenfels [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

  13. Re: Not stopping daemons, where are we?


    [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/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iD8DBQFIbxZ7Xk7sIRPQRh0RAnboAKCvhsUjfSluwxRE60odT2 Ve4vRDLwCfRAle
    iBN9Z5b9hfJ0t1iBd+U0YtE=
    =/TRu
    -----END PGP SIGNATURE-----


  14. Re: Not stopping daemons, where are we?

    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

  15. Re: Not stopping daemons, where are we?

    * Peter Samuelson [080705 02:37]:
    >
    > [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.


    In addition to Steve's response, there is also the issue of ordering.
    Some packages (by design or sysadmin configuration) require other
    services to be running during their shutdown.

    ....Marvin


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

  16. Re: Not stopping daemons, where are we?

    In article <20080705063643.GB24276@p12n.org> you wrote:
    > 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?


    Thats not the point. It is a quesion of sequence. When you get the killall5
    sigterm, then everybody else also gets it. Especially maybe your file
    service server. So you might not able to save.

    Gruss
    Bernd


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

  17. Re: Not stopping daemons, where are we?

    * Bernd Eckenfels

    | In article <20080705063643.GB24276@p12n.org> you wrote:
    | > 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?
    |
    | Thats not the point. It is a quesion of sequence. When you get the killall5
    | sigterm, then everybody else also gets it. Especially maybe your file
    | service server. So you might not able to save.

    If the local admin introduces other dependencies than what can
    reasonably be set as defaults, he should also make sure to adjust
    dependency and stop-level headers in init scripts. If he fails to do
    that, he might break his system, just like if he doesn't take care
    when doing all other kinds of maintenance to the system.

    We can give the admin reasonable tools to do his job, but we can't do
    it for him, nor can we divine any setup that an admin might come up
    with and which might confuse the tools we have provided.

    --
    Tollef Fog Heen
    UNIX is user friendly, it's just picky about who its friends are


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

  18. Re: Not stopping daemons, where are we?


    [Hai Zaar]
    > 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/.
    > 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 is already possible using the "flag" represented by the symlinks
    in /etc/rcX.d/. If the package maintainer do not want the script to
    run in runlevel 0 and 6, the symlinks will be missing. If the
    sysadmin want to run the script anyway, the symlinks can be added.
    The package system will keep the symlinks and the sysadmin should get
    what he want.

    Happy hacking,
    --
    Petter Reinholdtsen


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

+ Reply to Thread