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