[lsb-discuss] LSB Spec Authority 2004-09-24: Init scripts, deprecated commands
tobias.burnus at physik.fu-berlin.de
Wed Sep 24 12:26:30 PDT 2003
(I should join the SA call some day)
| Deprecated differences
| [...] Stuff to do after applying that patch: [...] In chmod, chgrp,
| chown, and sleep, need to get rid of synopsis which no longer makes
| sense (Kingdon to do that).
There are other command manpages which can be removed; their purpose has
been obsolated by the removal of --help and --version: nl, nohup, paste,
pathchk, printf, and pwd.
| [...] Would be nice to get more feedback on whether distros plan/want to
| implement all this stuff.
Colour annotated diff (including todays $named change):
(Colors: Changes since 12 August 2003 are marked in red while before 12
August 2003 are marked in green.)
As far as I know (sorry only for SuSE, Debian and RedHat 9):
(Please correct me, if something is wrong.)
|| Init Script Actions
This section doesn't affect the distributions
|| Comment Conventions for Init Scripts
SuSE: Supports Should-Start since X-UnitedLinux-Should-Start has been
introduced (forgot when)
Debian: Supported since 24 Jun 2003, lsb_1.3-1
RedHat: Not yet, no comment so far (Tacking bug:
Note that Should-Start is not required.
|| Installation and Removal of init.d Files
[Exit with 1 when dependency is not fulfilled]
Debian: Complies since 24 Jun 2003, lsb_1.3-1
(Previously it always deleted/installed the script, even
if the dependency was not fulfilled)
RedHat: Not tested (no root account on a RedHat 9 -- and
install/remove_initd are binaries)
|| Init Script Functions
[Method used to get status]
Some of the changes where not much liked by the distributions,
especially regarding the choice whether other means that the PID should
be used. The current version ('compromise') reads like this:
|| Compliant implementations may use other mechanisms besides using
|| those based on pidfiles, unless the -p pidfile option has been used.
(Only) if the last part after the comma is dropped, SuSE, RedHat and Debian
fulfill this, I think. (Still need to dig through the Debian's
start-stop-daemon code to make sure this claim is right.)
One might still deside to drop the latter part. Reasoning for keeping
it: This makes sure that one can start a daemon more than once since
otherwise the wrong one might be killed.
For a lengthy discussion, see:
|| The method used to determine the status is implementation defined,
|| but should allow for non-binary programs.
RedHat and SuSE fulfill this requirement, Debian does not. See bug
Also burried in the start-stop-daemon code.
|| [-p pidfile]
Debian: complient since 10 Sep 2003, lsb_1.3-4
RedHat: Tracking bug (with patch) at
|| should return the LSB defined exit status codes.
killproc (w/o signal when process not running => returning 0)
since SuSE 9.0
Debian: basically supported for a longtime, minor fixes and killproc
behaviour since 10 Sep 2003, lsb_1.3-4
RedHat: with exception of this killproc, complient. This is fixed in the
patch to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99325
(The reason that killproc shall return 0 in this case: Then one can use
it for "stop)" without the need to check $?.)
|| [pidofproc] Only pids of running processes should be returned.
Debian: Added 10 Sep 2003, lsb_1.3-4
|| If a program has been terminated, the pidfile should be removed if
|| the terminated process has not already done so.
(Reasoning: The daemon cannot do it, if SIGKILLed.)
I think SuSE does so, Debian does not, and RedHat does remove it.
More information about the lsb-discuss