[lsb-discuss] Re: REVIEW: System Initialization

Tobias Burnus tobias.burnus at physik.fu-berlin.de
Fri Jun 13 06:40:17 PDT 2003


Hello Mark, hi all,

>> killproc [-p pidfile] pathname [signal]
>> This stops the specified program. The program is found using the algorithm
>> given by pidofproc. If a signal is specified, using the -signal_name or
>> -signal_number syntaxes specified by the kill command, the program is
>> sent that signal. Otherwise, a SIGTERM followed by a SIGKILL after some
>> number of seconds is sent.
>> Compliant applications may use the basename instead of the pathname.
>> killproc should return the LSB defined exit status codes. It shall
>> return 0 if the program has been stopped or is not running and not 0
>> otherwise.

> So the way I read this is if I call "killproc <daemon> -SIGUSR1", kill
> will be executed on the item w/ a signal type of SIGUSR1, and then killproc
> needs to check if the application stopped and return a 0 if it did, not
> 0 if it did not.
> Is this correct?  Or should the 0 and not 0 return codes be based on if
> the kill "succeeded"?
Well, first you have to use -USR1 not -SIGUSR1 (since the signal in kill
is USR1 and not SIGUSR1). Hmm, this is a difficult question. For no signal
it is clear: It should be always "0" unless the program is no even
kill-9-able. But for user defined signals (like USR1) it becomes more
difficult. But what are real-world scenarios?

autofs: a USR1 (= TERM) means that automount should try stop as soon
as it can unmount a directory. In this case it makes sense that either
"0" (has "immediately" stopped) or != 0 (is running) is returned.
(what means "immediately"?).

But what for "reload" or other purpose - like mathematica's license server
(kill -USR1 causes a dump to /tmp/mathlm.dump with the status
information).

Hmm, maybe only for no signal (= TERM, sleep, KILL) the current exit code
should be used (99% of use in "stop"). And otherwise the exit code should
be more verbose. Maybe SuSE's "7" (= program not running) is not that bad
after all (they convert the 7 into a 0 for the init script exit code,
this reflects the error code for "status").

The problem is that the standard should not force to many changes to the
current implementation, like fancy checks in killproc.


By the way, what does "3 - program is stopped" actually mean? Not running
or that what happens when one sends a SIGSTOP?


> Specifies that /var/run/basename.pid shall be used.  But I don't see a
> format to this specified anywhere.  I am assuming that the format is
> single line, with whitespace seperating pids, such as: "X Y Z" (where
> X,Y and Z are 3 pids that basename occupies.)

There is also an additional question: How many PIDs should checkproc
return? All? And in which form.
Debian's pidofproc which uses as a fallback "pidof -s" only returns one,
while SuSE's checkproc returns all (like "pidof" w/o "-s").

> Is this correct, should this be specified somewhere as a clarification?
> (This matters when the application writes it's pid file and not
> start_daemon.)
Should start_daemon ever write the PID into the file? Debian's
start-stop-daemon does this, for instance, only when --make-pidfile is
used.


Tobias





More information about the lsb-discuss mailing list