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, [EMAIL PROTECTED] 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
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
