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

Re: RFC: initscript policy proposal



On Thu, Nov 02, 2000 at 03:03:55AM -0200, Henrique M Holschuh wrote:
> Because there is no guarantee that a non-sysv initscript system will work
> 100% right if the /etc/init.d files are called directly. One of the benefits
> of invoke-rc.d is abstracting the initscript-call layer so that deploying
> such initscript systems is not impossible, just difficult :-P

A "non-sysv initscript system"? Like filerc, that invoke-rc.d presumably
already supports? Huh?

Actually, a better reason to insist on people using invoke-rc.d with
--force would be to fix problems like those described in bugs like 10813.

> invoke-rc.d also has one extra advantage if it is the single point of access
> to run the initscripts: One could easily fire up a text editor and add
> initscript accounting (why? don't ask me, I don't need it), add a
> syslog-every-initscript-call trace...

That's not really that useful, because if anyone wants to avoid the
accounting they can just invoke the script directly....

> > > We attempt to maybe-restart the daemon. If it suceeds, that takes care of
> > > our problem (maybe-restart only restarts an already-running service). If it
> > > fails, what should we do *by default*?
> > maybe-restart isn't really an option, no scripts implement it.
> No, but any services which might benefit from it will, given the proper
> amount of maintainer prodding by users who need it. 

I don't really think it's a good idea to call maybe-restart for scripts
that don't implement it.

Perhaps it'd be better to have

	invoke-rc.d foo maybe-restart

be the way of calling /e/i/foo maybe-restart so it won't get invoked
when it's not supported?

Cheers,
aj

-- 
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: pgpkFzIVqD6e2.pgp
Description: PGP signature


Reply to: