Blair Zajac <blair@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. 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. 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. 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. 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. "Executable StartupItem keywords may not be used together with any of the wrapper StartupItem keywords." 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. Mark