[lsb-discuss] Re: LSB/WIP init script changes (fwd)
tobias.burnus at physik.fu-berlin.de
Mon Jul 7 01:40:40 PDT 2003
On Wed, 2 Jul 2003, Tobias Burnus wrote:
Make a sentence more readable:
> Index: initfunctions.sgml
> RCS file: /cvsroot/lsb/spec/wip/sysinit/initfunctions.sgml,v
> retrieving revision 1.3
> diff -u -r1.3 initfunctions.sgml
--- initfunctions.sgml 17 Jun 2003 17:57:56 -0000 1.3
+++ initfunctions.sgml 2 Jul 2003 15:47:54 -0000
@@ -69,7 +69,7 @@
pidofproc should return the LSB defined exist status
codes for "status". It shall return 0 if the program is
-the process is running and not 0 otherwise.
+running and not 0 otherwise.
Note that both SuSE/UL and Debian now include support for the
Should-Start/Stop function and for the other changes proposed.
Should-Start tracking for RedHat:
(Missing access a RH computer I cannot check the rest.)
> (2) Spec Auth - July 2, 2003 - http://www.linuxbase.org/talks/sa20030702.html
> > Not in WIP document:
> > 677746 [Enhancement] start_daemon should have a PID file argument
> This is actually part of the WIP
> > In WIP document:
> > 677745 Should a pid file be deleted by killproc
> This is actually _not_ addressed in the WIP
(3) Fixed init script issues by the WIP document:
[ 540950 ] Init script Functions: Several details are unclear
[ 677737 ] Exit status for killproc, start_daemon, pidofproc
[ 677739 ] [Enhancement] pathname for killproc/pidofproc
[ 677746 ] [Enhancement] start_daemon should have a PID file argument
[ 677752 ] should-start
(4) Not adressed
[ 568246 ] Init action: [force-]reload and stopped service
For restart and try-restart the situation is clear, for
force-reload it is undetermined, reload usually doesn't start a
The problem is that each single distribution isn't consistent with
its own init scripts; it is usually reload or restart, reload/try-reload
might be a better solution ...
[ 545387 ] startup script tests needed
On my agenda as soon as WIP wents in, need to get some ideas how to
test, though. See below.
[ 653167 ] Output from init scripts is described vaguely
Probably not completely solved. The wording regarding the log_*_msg
is clearer in the WIP as in gLSB 1.3 though.
[ 677744 ] the behaviour of start_daemon is currently unclear
The problem are scripts (/proc/<pid>/exe != pathname) if the checking
isn't done using (only) the PID file. Affects also killproc and
[ 677745 ] Should a pid file be deleted by killproc
Probably yes - if the program is not running (or after SIGKILL ...)
[ 677749 ] Forking of programs which don't detach themself
SuSE/UL: automatically, Debian --background
[ 740760 ] $named boot facility confusing
I think it is ok, but I think someone want's to improve it even more
(haven't tracked that bug)
[ 764725 ] wrong argument to install_initd
I don't seen the point actually (I commented in the bug)
[ 765895 ] Default-Stop definition unclear
It is in principle in the spec in a unambiguous form, but it takes quite
some time to catch its meaning.
[ 765901 ] PID format not defined (PID file + pidofproc)
Should be clear, but might not be clear.
(it also existed a pidofproc version which only returned the first of
(5) LSB Spec Authority: 'Tests [for the init script specs] would be
great, as would sample implementation. Kingdon to add statement like
"these are unlikely to make the real spec until someone writes some tests"
and add to WIP document. Kingdon to ask Burnus what his plans are.'
The problem with tests it how does one test whether the install_initd does
the right thing since we cannot check the result in e.g. /etc/init.d/rc?.d.
My idea was to check whether install_initd chocks on valid files (i.e.
exit status code != 0), installs init files with known unsatifiable
dependencies (exit = 1); analogous with remove_initd.
start_proc, killproc and pidofproc can also be tested (killing of
non-existing process etc.) but bug 677744 makes things not easier (need to
use a binary daemon not a simpler PERL daemon). I try to collect a list of
testable things soon.
For the sample implementation: Maybe one can use an existing
implementation and modify it? The problem is how clever a given
implementation can make use of /proc/<pid>/*. I know that SuSE makes havy
use of it, but also Debian does (see e.g. bug 677744 for the problems it
causes). The gLSB does basically only require to check
Regarding the test of ISV init script: No concept developed so far, but
there are none which formally applied for a certificate (though some use
at least the init script specs for their scripts).
More information about the lsb-discuss