startupitem.pidfile options

[markd at macports.org]

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