Blair, I see. That's fine then. I just wanted to be sure there was a reason for making it a script startupitem and there is. I'm cc'ing James (master of all things startupitem) just in case he knows why the executable startupitem type wasn't adequate in this case. It seems like it should have worked. Thanks for fixing the port. Mark
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but it couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track of dhcpd running and deamonizing itself.
I haven't read the guide yet. What do you suggest? Putting a -f to dhcpd so it stays in the foreground?
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support [ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaw... ]http://www.orcaware.com/svn/
On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote:
Hi Blair,
Executable startupitems are the preferred type. Daemondo can track pids automatically and reliably restart an application if it quits. See the guide on this:
[ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.mac... ]http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to reverting to a "script" startupitem. Or is there something I am missing particular to dhcp?
Hi Mark, So it looks like the bit magic that got this to work is the -f command, which basically tells dhcpd not to daemonize, which would be a good thing in our case, as the process of daemonizing would look to daemondo or launchd as if dhcpd were exiting, which would cause the constantly restarting behavior Blair described. The startupitem.name spec should be completely redundant and unneeded; the name will default to the name of the port, which is dhcpd, right? Does that answer your question? James On Jan 13, 2008, at 1:25 PM, markd@macports.org wrote:
Blair,
I see. That's fine then. I just wanted to be sure there was a reason for making it a script startupitem and there is. I'm cc'ing James (master of all things startupitem) just in case he knows why the executable startupitem type wasn't adequate in this case. It seems like it should have worked. Thanks for fixing the port.
Mark
On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote:
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?
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but it couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track of dhcpd running and deamonizing itself.
I haven't read the guide yet.† What do you suggest?† Putting a -f to dhcpd so it stays in the foreground?
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support [ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaw... ]http://www.orcaware.com/svn/
On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote:
Hi Blair,
Executable startupitems are the preferred type.† Daemondo can track pids automatically and reliably restart an application if it quits.† See the guide on this:
[ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.mac... ]http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to reverting to a "script" startupitem.† Or is there something I am missing particular to dhcp?
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Hi guys, I put dhcp back to the startupitem.executable but using -f. The port's name is dhcp and the daemon's name is dhcpd, so startupitem.name is needed. Regards, Blair James Berry wrote:
Hi Mark,
So it looks like the bit magic that got this to work is the -f command, which basically tells dhcpd not to daemonize, which would be a good thing in our case, as the process of daemonizing would look to daemondo or launchd as if dhcpd were exiting, which would cause the constantly restarting behavior Blair described.
The startupitem.name spec should be completely redundant and unneeded; the name will default to the name of the port, which is dhcpd, right?
Does that answer your question?
James
On Jan 13, 2008, at 1:25 PM, markd@macports.org wrote:
Blair,
I see. That's fine then. I just wanted to be sure there was a reason for making it a script startupitem and there is. I'm cc'ing James (master of all things startupitem) just in case he knows why the executable startupitem type wasn't adequate in this case. It seems like it should have worked. Thanks for fixing the port.
Mark
On Jan 13, 2008, at 12:42 PM, Blair Zajac wrote:
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?
Hi Mark,
I was seeing the following:
1) One dhcpd would start.
2) Every 10 seconds thereafter, another dhcpd would be started, but it couldn't bind to the port since the first one was running.
It appears that the startupitem infrastructure wasn't keeping track of dhcpd running and deamonizing itself.
I haven't read the guide yet.† What do you suggest?† Putting a -f to dhcpd so it stays in the foreground?
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support [ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fwww.orcaw...
On Jan 13, 2008, at 12:11 PM, markd@macports.org wrote:
Hi Blair,
Executable startupitems are the preferred type.† Daemondo can track pids automatically and reliably restart an application if it quits.† See the guide on this:
[ https://owa016.msoutlookonline.net/owa/redir.aspx?URL=http%3a%2f%2fguide.mac...
]http://guide.macports.org/#reference.startupitems
Given how startupitem executables work, I don't see an advantage to reverting to a "script" startupitem.† Or is there something I am missing particular to dhcp?
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
participants (3)
-
Blair Zajac
-
James Berry
-
markd＠macports.org