Re: RFC init.d actions [force-]reload and non-running programs
On Sun, 14 Jul 2002, Tobias Burnus wrote:
> I recently came across the problem that I didn't know what happens if I
> /etc/init.d/foo force-reload
> and foo is not running.
Debian policy says:
cause the configuration to be reloaded if the service
supports this, otherwise restart the service.
So it is badly defined in policy, and behaviour is not determined if the
service supports reloading, but it is not started. This is a problem in
> 'force-reload' was divided in two about equally common actions: restart
> and sending a HUP. A slight majority faviours the former.
Just as I feared. As I said, behaviour is undertemined.
> What I'd like to see is that both the Debian Policy and the gLSB is
> changed to remove this indetermined behaviour.
Please set it up as 'force reloading if the service is running', since that
one is far more useful than a 'force reloading if it is there, otherwise
start' which can be easily implemented as foo force-reload || force start...
> therefore it matters much more whether a program is running or not. For
Debian policy is your enemy here. You need to know the status of a package
(when it is removed) to know if a service is ok or not using only the init
scripts. This is yet another problem in current policy, and it is
incompatible with the LSB requirements, as well.
> but I can live with both. One may even consider to add further init.d
I was going to propose a 'restart-if-running', to do that. In that case,
'force-reload' should call reload if this does a complete configuration
reload (apache 1.3.xstyle 'everything but plugins' wouldn't qualify), but
not start a service ever...
Might as well kill two birds with one single stone, but that depends on the
LSB guys agreeing on what we want force-reload to do.
> The LSB wants to define this in gLSB 1.3 using the most common behaviour
> by the Distributions, see bug
I doubt the most common behaviour will be useful here, since it is somewhat
close to 50%, I fear. Anything with more disparity than 30%/70% already
makes the 'most common behaviour' a bad reason to choose something, IMHO...
> PS: I know that a LSB distribution does not need to have LSB conform init
> scripts, but a common behaviour helps. :-)
Indeed it does.
> PPS: One thing which is gLSB and SuSE, RedHat and some others have is the
> 'status' action for init scripts, which I really miss. In my humble
It is often difficult to implement it in a proper way, but yes, it is
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org