startupitem.pidfile options

[James Berry]

Hi Mark (and others interested)

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

	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 hope that helps. Thanks for all your efforts in documenting and  
testing the startupitem / daemondo behavior. I haven't answered your  
questions below, but I hope I've given enough information that you  
could now answer them for yourself. Let me know if you have questions.

James

On Oct 25, 2007, at 12:06 PM, markd at macports.org wrote:

> James,
>
> I don't fully understand the startupitem.pidfile options.  I think  
> I've
> got the documentation improved for startupitems, but like to  
> improve it
> some more.
>
> Here are the current new docs on the options:
>
> -------------------------------
> Pidfile handling options:
>
> none - The daemon is not to use a pidfile.
> auto - The daemon generates its own pidfile.
> manual - The daemon never generates a pidfile; the StartupItem must  
> manage
> the pidfile on its own.
> clean - The daemon generates its own but will not delete it; the
> StartupItem must delete it.
> ---------------------------------
>
> Question 1)
>
> I have a startupitem that creates the pidfile like this:
> 'startupitem.start       "${nedimonitorbin} & echo \$! >
> ${nedimonitorpid}"'
>
> I thought "manual" would be the best option.  But "manual" deleted my
> pidfile when launchctl executed.  Why would that be?  Also, it sets
> "<string>--pid=exec</string>"  in the .plist.  Is this correct?
>
> I had to use the "clean" option, and it works fine, but I don't  
> understand
> why "manual" worked as it did, or why "clean" works since it says "the
> startupitem must delete it" and mine doesn't.  Should the docs say
> "daemondo must delete it", instead of "StartupItem must delete it"?
>
> Question 2)
>
> none - This means that pidfile startupitem.pidfile disabled, correct?
> Same as not using the startupitem.pidfile keyword at all.
>
>
> auto - This option deletes the pidfile as well, correct?
>
> clean - "The daemon generates its own but will not delete it; the
> StartupItem must delete it".  Why must implies the pid file should be
> deleted.  Why?
>
>
> Mark
>