[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Disallowing explicit delays in the stop target of init.d scripts?

  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.

  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.

  Do I have support in taking this issue to debian-policy so that 
policy will be amended to allow such delays only on extreme cases?

  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 
       shutdown -h now 
   would be treated differently then 
       shutdown -t n    (with n > 0)
   by the init.d scripts. 
2. Having an emergency target and EnnName links in /etc/rc?.d, as well
       shutdown -e      (emergency)

  Yet until a solution is implemented I think that policy should, in
general, explicitly forbids such delays.

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