Re: Disallowing explicit delays in the stop target of init.d scripts?
In article <[🔎] 20040304221951.GA7506@rakefet>,
Shaul Karl <shaulk@actcom.net.il> wrote:
> The desire to terminate a process in a clean manner motivates
>maintainers to use constructs like
>
> start-stop-daemon --retry -HUP/60/-TERM
>
>or otherwise implement delay in the stop target of init.d scripts.
>See, for example, http://bugs.debian.org/235196. I didn't search for
>other examples. Yet the fact that the maintainer of the concerned
>package had consensus for this delay on the #debian-devel channel
>suggests that sooner or later it will happen again.
Ofcourse. If you don't shut down squid, inn, postgres, mysql
properly (and wait for them to be terminated) you might as
well just turn off the power - the result could be just as desastrous.
> I strongly feel that this should be discouraged. Although a clean
>termination of a process is desirable, I believe that the stop target is
>not the right place for that. This is so because first and for most,
>when someone wants to bring the machine down then his wish should be
>carried out as quickly as possible. Isn't small tools for well defined
>tasks part of the Unix philosophy? Isn't time a major component of a
>well defined task? In particular, those delays japordize (how is this
>word spelled? I mean stand in the way, dismiss) the usage of UPSs
>(Un-interruptible Power Supplys) and UPS monitoring software. The reason
>for this is that the most important task of the UPS is to keep the
>machine alive for a duration that is considered safe for the health
>of the machine. However when the UPS has decides that this time is over,
>the machine should be brought into a halt as soon as possible.
One of the other reasons to use a UPS is *because* the system then
has the time to shutdown data critical processes properly. If your
UPS only gives you 5 seconds notice instead of a few minutes, it's
a toy.
> I further believe that the solution for the clean termination problem
>might be done by isolating the `here and now' targets. Possible ways
>might be:
>
>1. A
>2. Having an emergency target and EnnName links in /etc/rc?.d, as well
Why make it more complicated, the current system works as it is intended.
Yes, for example inn takes a long time to terminate. If you don't
like that, do not run inn. If you do need to run inn, well it needs
time to terminate or it might corrupt its database and not run at
all anymore after boot.
A much better way would be to allow services to shutdown simultaneously,
so the wait times do not add up. Ofcourse the same goes for startup,
so we're back at the dependency-based init system, which is something
that people say they will work on for sarge+1.
Mike.
Reply to: