Subject: [32751] net/dhcp startupitem

[markd at macports.org]

>Mark,
>
>It works fine if I use this:
>
>startupitem.create††††† yes
>startupitem.name††††††† dhcpd
>startupitem.executable† ${prefix}/sbin/dhcpd -f
>startupitem.netchange†† yes
>
>How's that?

The startupitem executable is preferred if it works automatically I think;
but if it doesn't for some reason at that point I see no obligation to
prefer a workaround using the executable type to using the "script" type
startupitem.  So I think leaving it as you had it is fine; I can't comment
on whether starting in foreground mode is a good method, but as I said
under the circumstances your current solution is perfectly fine in my
opinion.
>
>
>On Jan 13, 2008, at 12:36 PM, Blair Zajac wrote:
>
>> Hi Mark,
>>
>> The guild says this:
>>
>> "startupitem.executable.† Specifies the name of the daemon to be run
>> in the background. It may have multiple arguments, but they must be
>> appropriate for a call to exec; arbitrary shell code may not be used."
>>
>> Should the actual daemon remain in the foreground so that the parent
>> parent process can wait() on it?† Should the daemon make a PID file
>> in a known location?
>>
>> The guide could expand on this a bit.

I hope James is listening out there and can comment on this.  I think if
one really wanted to use an executable startupitem, I think
statupitem.pidfile could be used and that particular use isn't documented,
but probably because I didn't expect the need for it to ever occur, as it
has for dhcp.  But as I said, if startupitm executable doesn't work in
default setup, then I see no further advantage in using it as opposed to a
"script" startupitem.  Thanks for giving this attention.

Mark