Re: Disallowing explicit delays in the stop target of init.d scripts?
On Fri, Mar 05, 2004 at 10:42:05AM +0000, Miquel van Smoorenburg wrote:
> 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.
>
Right. There is already a long list. It will probably get longer in
the future. Something like policy should interfere from now on to balance
between the interests of the packages and the interest of the whole
system.
> > 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.
>
The UPS has already hard time balancing between unpredictable events
like when the mains power will get back and whether the system won't
suddenly draws more power, and the need to keep the data structures of
each process, including the fs, consistent. Even with constant draw of
current, the calculation of the energy that is stored in the batteries
is far from being accurate. Something like policy should help him with
this task. I believe that 2 minutes are considered reasonable by today
standards. As a result, letting mgetty-fax, or some other process, take
1 minute out of it gives you less time for squid and inn.
> > 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.
>
But what if I don't mind inn termination time? I will run it. Only
that I won't pay attention to emergency shut downs. Does squid's
hardware requirements mentions the capabilities of the UPS? Does it
mentions the duration of a proper shutdown of the squid process? That
is why policy should interfere. It is an aspect that usually gets
overlooked, partially because it is hard to take into account.
And if I do mind inn termination time but also need it, I will run it
on a dedicated strong machine. Yet as a vendor of DFSG software for Unix
we should make things as efficient as possible so that there will be
less need for either dedicated or particularly strong machines.
> 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.
>
This still have the possibility that the shutdown (stop) scripts will
do as they like since, from their point of view, it is the best thing.
There should be something to guard that there is a known upper bound for
the duration of the shutdown process. I believe this is policy's job.
--
"If you have an apple and I have an apple and we exchange apples then
you and I will still each have one apple. But if you have an idea and I
have an idea and we exchange these ideas, then each of us will have two
ideas." -- George Bernard Shaw (sent by shaulk @ actcom . net . il)
Reply to: