daemondo defeats purpose of launchd?

[James Berry]

Hi all, and sorry I haven't chimed in on this thread earlier. I'll  
answer a few questions below...

On Sep 4, 2007, at 1:47 PM, markd at macports.org wrote:

> Blair Zajac <blair at orcaware.com> writes:
>> Looks good Mark.
>>
>> It doesn't explain why one would use launchd or daemondo.  Is this  
>> the
>> appropriate place to put it, or is it described elsewhere?
>
> Hi Blair,
>
> Yes you're right it doesn't say, and this would be the appropriate  
> place.
> Fact is, I'm not sure the answer.  James' original notes said that
> startupitem.executable was the preferred type, but it didn't say  
> why.  If
> daemondo doesn't monitor and restart daemons, as I guess it can't  
> since it
> only knows about scripts, then perhaps that is the reason.

daemondo will indeed quit when it detects that the launched process  
has quit, and thus will "keep alive" the process, since launchd will  
then restart daemondo. In this way, daemondo acts as a shim or  
adapter between the scripts supported by the startupitem command, and  
the single process expected by launchd.

The reason that startupitem.executable is preferred is that this  
gives the best possible chance that daemondo will be able to detect  
the death of the launched process: since daemondo can launch the  
process, it can also detect when it quits, stop it, etc.

For those cases where startupitem.executable cannot be used, daemondo  
also supports the startupitem.pidfile commands that allow the  
process' pidfile to be monitored: daemondo will read the pidfile and  
watch for the death of that process.

So daemondo, and thus launchd, will be aware of the daemon process  
death (and be able to restart the daemon process) only under two  
circumstances:

	(1) startupitem.executable was supplied (thus daemondo starts the  
process)
	(2) startupitem.pidfile was supplied (thus daemondo reads the  
process id)

Under all other circumstances, daemondo will not know that the daemon  
process has died, and will not exit when the process does die, and  
thus launchd won't restart the process since it doesn't  know it  
died. Put another way, if daemondo can know the process has died,  
then launchd will know too, but not otherwise.

> But since so
> many apps just have startup scripts that don't monitor and restart  
> their
> daemons, it seems odd to call it the "preferred type" since if that  
> is to
> be done whenever possible (even when developers provide startup  
> scripts),
> we'd be establishing a higher standard with ports than the  
> developers who
> created the programs consider necessary.  So I wonder if the "why"
> question doesn't come down to:
>
> 1) If a port author wants the daemon monitored and restarted if it  
> dies,
> use an executable startupitem type.

Note that for simplicity, startupitem.executable is handled by  
daemondo at present. This has two purposes:

	- It keeps the startupitem generating code a little simpler.
	- It allows the potential support for higher value services to be  
provided by daemondo. In particular, note daemondo's --restart- 
netchange option, which can be quite useful, but for which there is  
no current support by the startupitem keys.


> 2) Otherwise, use a wrapper type (daemondo) startup script if the
> developer provided a startup script that works ok on the target  
> platform
> and the deamon isn't unstable for some reason.

In most cases, the second step after using startupitem.executable  
should be to make sure that the pidfile is identified (if there is  
one) since this will allow daemondo to track the process and will  
lead in most cases to satisfaction.

> 3) If the developer didn't provide a startup script or one that  
> works ok
> on the target platform, you may use either executable or wrapper
> startupitem types.  Unless we can establish executable startupitems  
> are
> *really* the preferred type for MacPorts, then the advice is:  
> executable
> if possilble and wrapper if not.

Yes, executable really are the preferred means, with pidfile close  
behind.

>
> If I can arrive at some answers on this I can clarify that section.
>>
>> Also, for startupitem.pidfile, the default is shown as
>>
>> Default: none | ${prefix}/var/run/${name}.pid
>>
>> is one for launchd and the other for daemondo?
>
> No and I struggled on that one because the startupitem.pidfile  
> keyword has
> two separate values: one specifies the pid handling behavior, the  
> other
> the pidfile path.  So there are two defaults for the one keyword.   
> Also,
> since the keyword is of a type "executable", it cannot be used with
> wrapper startupitems.

Hmm. I don't get your distinction between these "types". The pidfile  
keyword is likely used only if executable is not.

> "Executable StartupItem keywords may not be used together with any  
> of the
> wrapper StartupItem keywords."

Hmm. That may  be too strongly put. I'll have to read your section,  
which I haven't yet.

>
> But that should be stated clearly in the intro to the topic, but it  
> isn't
> so it is easily missed.  I can make it all more clear and I will do  
> that.
> Hopefully others will know the answer to the first question and  
> whether
> executable startupitem types are truly "preferred".  Your feedback is
> helpful; thanks a lot.


Please let me know how I can clarify things any further. Thanks for  
the work you're putting into the documentation.

James

>
> Mark
>