Not really MacPorts problem, I don't think.

[Bill Christensen]

On 1/24/15 12:32 AM, Joshua Root wrote:
> On 2015-1-24 14:40 , William H. Magill wrote:
>>> On Jan 23, 2015, at 2:36 AM, Joshua Root <jmr at macports.org> wrote:
>>>
>>>> At 8:42 PM -0600 1/22/15, Ryan Schmidt wrote:
>>>>> So launchd is launching apache too early. I believe there are some
>>>>> keys one can use in a launchd plist that would affect when launchd
>>>>> tries to launch a service. If you can find a launchd plist key/value
>>>>> that fixes this issue, MacPorts could be enhanced to offer portfile
>>>>> authors a way to use that key, or to use that key/value by default
>>>>> even.
>>>> I'm not expert, but would the NetworkState key help?  See:
>>>>
>>>> http://launchd.info/
>>>>
>>>> Goto "Configuration", scroll down to "...Depending on Network Availability:"
>>> We do have startupitem.netchange.
>> I'm confused.
>>
>> The implication of "startupitem.netchange" :
>> "Cause the daemon to be restarted when a change in network state is detected."
>>                     https://guide.macports.org/chunked/reference.startupitems.html
>>
>> is different from "NetworkState"
>> "Setting this subkey to true will start the job when/while any network is/becomes available. Setting this subkey to false will start the job when/while all network connections are down."
>>                     http://launchd.info
> Yes, it's not the same thing, but it would probably fix the problem that
> started this thread.
>
>> And there is no indication on the guide.macports.org page as to what the output of "startupitem.netchange" might generate.
>>
>> i.e. no translation between the syntax of launchd and startupitems.
> It doesn't change how launchd handles the job, it simply adds
> --restart-netchange to the arguments passed to daemondo.
>
> As I've said many times in the past, the StartupItem code could really
> use some love. Especially allowing jobs to not use daemondo if they
> support running directly from launchd, and exposing more of launchd's
> functionality.
>
> - Josh
I agree, and I have hope that this thread might help me out with the 
same problem.  Not just Apache, but two other important services also 
need manual kicks on startup (postgresql and fetchmail). At the same 
time, a number of other server processes also installed via MacPorts 
start up just fine every time.

Question: would this problem of Apache launching too early be influenced 
by DNS?  For instance, I've got some named SSL certs on the machine in 
question, and if I try to start a backup off network without disabling 
the SSL conf, Apache chokes.  So I'm thinking that maybe in normal 
production startup it's also not getting a response from the dns 
matching the name and the IP before Apache tries to start - or the 
secondary IP addresses haven't kicked in yet, or something along those 
lines.

I think I've heard it's possible to set various startup items to "early" 
or at some delayed timing, but I have no clue as to how that would be 
done.  How early is "early"?  Is there a way to start them in a series 
to insure everything kicks on in the proper order?  How can we find out 
where these are failing to start?

Specifics, if you've got 'em, please.