RFC init.d actions [force-]reload and non-running programs
Hi,
I recently came across the problem that I didn't know what happens if I
enter
/etc/init.d/foo force-reload
and foo is not running.
Looking at the Debian Policy
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit
and at the Linux Standard Base (gLSB 1.2)
http://www.linuxbase.org/spec/gLSB/gLSB/iniscrptact.html
didn't tell me much.
I just did a survey by looking at the scripts in /etc/init.d
(Woody installation and - for what it is worth - SuSE 8). While for
'reload' most (but by far not all) of the scripts did either nothing or
send only a HUP (i.e. no restart) when using 'reload', the behaviour for
'force-reload' was divided in two about equally common actions: restart
and sending a HUP. A slight majority faviours the former.
What I'd like to see is that both the Debian Policy and the gLSB is
changed to remove this indetermined behaviour.
(We use a script based administration/update tool (an enhanced FAI) and
therefore it matters much more whether a program is running or not. For
local system the behaviour is less important since one can check the
result easier. Especially if one wants to restart the daemon only when
needed and not when a -HUP is available one cannot use 'restart'.)
For me it would be ok if 'reload' never starts a daemon and
'force-reload' would always make sure that the daemon is up and running,
but I can live with both. One may even consider to add further init.d
actions.
The LSB wants to define this in gLSB 1.3 using the most common behaviour
by the Distributions, see bug
http://sourceforge.net/tracker/index.php?func=detail&aid=568246&group_id=1107&atid=101107
Tobias
PS: I know that a LSB distribution does not need to have LSB conform init
scripts, but a common behaviour helps. :-)
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
opinion this would make also a useful addition to the Debian Policy ;-)
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: