Re: Re: REVIEW: System Initialization

Tobias Burnus wrote:
> Hello Mark, hi all,
> 
> 
 >>> ...
>>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

Ya, simple typo, I knew that.. :)

> 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?
> 

The one I was thinking of directly was a simple -HUP to cause a "reload" 
action in a lot of daemons.  But I picked USR1 specifically so that 
other instances of a more undefined nature would be through of, exactly 
as you did.

 > [...examples...]

> 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.

I thought that was the purpose of a standard though, to unify different 
distributions and make them all work consistantly.  If you want to take 
the POSIX everyone wins way out here.  My suggestion is to keep the 
current language for the SIGTERM then SIGKILL default action, and add 
language that says the return codes are undefined for manual signals. 
(I.e. tell LSB applications to just ignore it and assume it worked.) 
Personally I'd rather have something on the order of:  current language 
for default signal arrangement..  0 return code for other signals 
(assuming that KILL didn't error).

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

My assumption is the status return code of 3 is the same as the 
non-status return code of 7.  i.e. Program Stopped is the same as 
Programing is not running.  (This might be an additional good 
clarification to make.)  Personally I hate the fact there are status 
return codes, and "regular" return codes.. but I think it's probably too 
late to change that.

>>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").

My immediate assumption is all.. and the format that I am using is white 
space deliminated on a single line.  But that was chosen just based on 
the samples I had looked at on Red Hat and Debian systems.  But it 
really should be standardized.

>>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.

In all previous readings I had just made the assumption that it's job 
was to create the pid file as part of the command.  I don't see any 
other reason for start-stop-daemon to exist then.  (Since all you would 
have to do is run "pidofproc" to see if there are existing processes if 
not just run the program and background it.)

So this is a good question, should start_daemon be populating PID files? 
  My immediate answer is yes it should be, if the user doesn't want that 
behavior they should manually launch their app and manage their pidfile. 
  But I havn't checked any other distributions to see if that is happening.

--Mark