startupitem.pidfile options

[markd at macports.org]

James Berry <jberry at macports.org> writes:
>>> 	exec:
>>> 		daemondo will remember the pid generated from execution of
>>> the .executable
>>> 		or .start command, and will use this to track operation of the  
>>> daemon.
>>> 		If a pidfile is also specified, then daemondo will also write a
>>> pidfile to contain
>>> 		the pid (note that this is only for your sake, as daemondo doesn't
>>> need this for
>>> 		its own operation).
>>
>> exec = manual?  The man page (and new docs) use "manual".  And I don't
>> understand under which circumstances this option is likely to work.  I
>> suppose if remembering pids could be done in all circumstances, we
>> wouldn't need pidfiles at all.
>
>Yes, exec should be "manual". Sorry, I confused myself in mapping  
>between the parameters that daemondo takes, and those that the  
>startupitem.pidfile command takes.

Okay, but I still don't understand under what circumstances (for "manual"
pidfiles) a child process that is started could be remembered.  It seems
like that never happens (when not using .executable) and that is why we
use .pidfiles.

>> I understand that startupitems.executable is preferred and the  
>> reason why
>> (due to your previous explanations), but the nedi daemons are perl
>> scripts.  I thought startupitem.executable could only be used with
>> compiled commands, and wouldn't work for stuff like perl scripts.   
>> If that
>> does work startupitem.executable would be better, and I'd think  
>> we'd use
>> it for most everything.  As it is, there are few scripts that use
>> statupitem.executables.
>
>The determinant is not whether or not the item is itself a script or  
>a binary (this factor is irrelevant), but whether or not the item to  
>be executed is a process that will continue to run.
>
>Think of it this way:
>
>  - If the script/binary that you execute is _the thing_ that you  
>want to keep running, then you may and should use  
>startupitem.executable (daemondo will grab, hang onto, and monitor  
>the process id of the process it starts, even if it's a shell of some  
>sort).
>
>  - If the script/binary that you execute is not going to continue to  
>execute, but is going to turn around and launch something else that  
>will continue to run, then use startupitem.start (daemondo won't hang  
>onto the process id of what it starts; to find out what it needs to  
>monitor it really needs to read a pidfile).
>
>And yes, startupitem.executable is sorely under-utilized, probably  
>because people don't understand what it is, or because it's somewhat  
>more difficult to figure out, in many cases, what and how the  
>ultimate executable actually needs to be run. Things would be a lot  
>smoother if .executable was used more.

I get it now.  It is different than I thought, so I will use
startupitem.executable for nedi.  And I'll rewrite the docs to reflect it
as I understand it now. It seems very clear to me now after having worked
through it and getting your explanations.  If I can get this documented
fairly well, perhaps you won't need to explain it again later.  :)  I
really appreciate your patience and thoroughness in explaining it all.

Mark