startupitem.pidfile options

[James Berry]

On Oct 25, 2007, at 3:07 PM, markd at macports.org wrote:

> James Berry <jberry at macports.org> writes:
>> Let me try to explain the pipfile options. I'm expressing these in
>> terms of daemondo, but understand that something similar should
>> happen if a SystemStarter script is generated instead.
>>
>> 	none:
>> 		daemondo will not try to read, create, or write a pidfile for the
>> daemon process.
>> 		It's basically flying blind, and won't be able to detect if the
>> process dies.
>>
>> 	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.

>>
>> 	auto:
>> 		The started process is expected to create and destroy (when
>> appropriate) a pid file
>> 		that specifies the pid of the daemon process.
>> 		After starting the process, daemondo will try to read this pidfile
>> in order to scavenge the
>> 		pid of the daemon process to track.
>>
>> 	clean:
>> 		The started process is expected to create a pid file that specifies
>> the pid of the daemon
>> 		process, but is not reliable in always deleting it when the process
>> dies.
>> 		After starting the process, daemondo will try to read this pidfile
>> in order to scavenge the
>> 		pid of the daemon process to track, and will try to delete the
>> pidfile when it detects
>> 		that the process has died.
>>
>> Note that the startupitem.pidfile options above are mapped to
>> slightly differently factored native daemondo parameters.
>>
>> As a separate note, it looks to me like the nedi port that you
>> recently modified would be shorter, less verbose, and less prone to
>> failure if you specified the startup options in this way:
>>
>>  startupitem.create		yes
>>  startupitem.name		nedimonitor
>>  startupitem.executable	${nedimonitorbin}
>>
>> In other words, since it appears that it is $nedimonitorbin that is
>> the true deamon (your script is just storing its pid in a pidfile),
>> you really just need to tell daemondo to execute that command, and it
>> will remember the pid all by itself. You don't need to generate a
>> pidfile at all, and everybody is better off if daemondo just does all
>> the work and you don't have shell scripts to run. If you want a
>> pidfile for your own enjoyment, then specify a pidfile with exec, and
>> daemondo will store the pid there for you to examine.
>>
>> The case mentioned above is the best case, and one we'd like to work
>> for in all cases, but often there is no convenient executable for
>> daemondo to execute (being hidden behind multiple layers of scripts
>> etc), and the best we can do is tell it how to find the pid of the
>> actual deamon by reading a pidfile. Note that there are additional
>> failure modes inherent in such an operation (what if the daemon
>> crashes between the time that daemondo starts the script and the time
>> it gets a chance to read the pidfile)? (Daemondo looks for the
>> pidfile immediately after executing the start code, then begins to
>> poll for it at 1 second intervals thereafter, until it gives up doing
>> this).
>
> 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.

James