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

Re: RFC: initscript policy proposal

Gah. Do we have to keep cross-posting threads to multiple lists?

On Wed, Nov 01, 2000 at 01:03:17AM -0200, Henrique M Holschuh wrote:
> On Tue, 31 Oct 2000, Steve Greenland wrote:
> > > +     `update-rc.d' and the system administrator. Also, requests to restart a
> > > +     service out of its intended runlevels are changed to a stop request.
> > The last sentence causes a problem in the following (contrived?)
> > scenario.
> > 1. Daemon foo is not configured to run at current runlevel.
> > 2. I, the sysadmin, have started foo by hand.
> > 3. I do a apt-get upgrade, which includes a new versin of foo. Because
> > of "restart converted to stop", foo is stopped.

Whatever happens, the sequence:

	invoke-rc.d foo stop
	invoke-rc.d foo start

should match

	invoke-rc.d foo restart

in behaviour. (Often a simple restart's more desirable, but in some
cases it has to be split across an rm script and an inst script...)

> The "always right" way would be to make "maybe-restart" mandatory, and use
> that instead. Actually, I'd much prefer to have "maybe-restart" mandatory
> instead of optional, but I fear that would be considered too intrusive, as
> it would require a LOT of non-trivial coding.
> However, the difficult work required for a mandatory "maybe-restart" will
> need to be done to implement the LSB "status" mandatory option anyway. So
> _maybe_ it would be better to just make "maybe-restart" non-optional and be
> done with it. (Before anyone starts a flamewar over this, READ THE LAST

The LSB requirements you're describing here probably relate to the
init scripts of LSB packages, not any init scripts provided by the

> > I propose that instead of "restarts converted to stops" we just go with
> > "restarts ignored". I realize that this would cause the new version of
> > foo to be ignored, but that may be less surprising than having foo go
> > away completely,
> I am not sure which one is the lesser of the two evils: ignoring or stopping
> the daemon :-( 
> I spent some time thinking about that, and I decided that 'stop' was the
> safer approach, as it is very unlikely that a mission-critical component

The ignore option is probably better. If the maintainer wants to force
a stop (if the previous daemon will misbehave if its left running after
the new daemon is installed), it can be done by saying `/etc/init.d/foo
stop'. OTOH, having the stop only happen when it's expected to be running
isn't possible to fake.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgptCwekiem46.pgp
Description: PGP signature

Reply to: