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