***BOGO*** Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)

[Raphael Hertzog <hertzog@xxxxxxxxxx>]

(Cc -devel to seek input)

On Thu, 31 May 2007, Iñaki Baz Castillo wrote:
> Acording to the LSB specifications for init scripts [1]:
> 
> "For all other init-script actions, the init script shall return an exit
> status of zero if the action was successful. Otherwise, the exit status
> shall be non-zero, as defined below. In addition to straightforward
> success, the following situations are also to be considered successful: 
> - Restarting a service (instead of reloading it) with the force-reload
> argument
> - Running start on a service already running
> - Running stop on a service already stopped or not running
> - Running restart on a service already stopped or not running
> - Running try-restart on a service already stopped or not running"
> 
> So if I start a service that is already running I should receive 0, but
> "start-stop-daemon" returns 1 (error).
> 
> The option "--oknodo" changes the behaviour to the LSB recomendations but many
> services in Debian don't use this option and return 1 in the case I've
> quotted. This is very problematic for me when I try to use a Debian
> service init script with HeartBeat that expects to receive a 0.

I'm reluctant to change the default behaviour of start-stop-daemon at this
point. What do other people think of making --oknodo the default behaviour
and adding a new option to force the current default behaviour (exit with
failure if nothing had to be done)?

The alternative is to change policy and/or lintian to ensure that packages
are using --oknodo unless they have a good reason not to.

> [1] LSB specifications about init script actions:
> http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx