On Oct21, 2014, at 02:53 , Wim Lewis <wiml@omnigroup.com> wrote:
>
>> 2) AFAICS, this .plist file doesn't do anything about launchd's habit of
>> not waiting for the network to come up.
>> If true, the job will be kept alive as long as the network is up, where
>> up is defined as at least one non-loopback interface being up and having
>> IPv4 or IPv6 addresses assigned to them. If false, the job will be kept
>> alive in the inverse condition.
>
> On the other hand, it’s not unreasonable to have postgres running on a
> machine with only a loopback interface, depending on the use.
This, I think, shows the gist of the problem -- "Networking is up" is not
a clearly defined stated on modern desktop machines. Interfaces can come and
go all the time, and even things like ethernet may take a while to come up
during boot, or even depend on a user logging in if something like 802.11X
is used.
>> We might be able to put something in LaunchEvents that gets it to fire
>> when the network launches, but documentation is hella thin (and may only
>> be supported on Yosemite, where there are a bunch of poorly-documented
>> launchd changes).
>
> If one were desperate enough... it’s possible to dig through the launchd
> sources to make up for the gaps in the documentation (also on
> opensource.apple.com; there used to be a community-ish site for it at
> macosforge.org as well). It’s rough going, though, IIRC.
The correct way to deal with this would be to teach postgres to react to
connectivity changes dynamically. During postmaster launch, we'd ignore all
"listen" entries which mention non-bindable addresses. If the network
configuration changes, we'd rescan the "listen" entries, and attempt to
create any missing sockets.
OS X provides an API (via the SystemConfiguration framework IIRC) which allows
to subscribe to networking-changed notifications. I believe systemd provides
something similar via dbus or some such.
Whether or not doing this is worth the effort though, I don't know. I guess
it depends on whether postgres on OS X is actually used for productions --
my guess is that most installations are for development and testing purposes,
but maybe my view's biased there.
>>> (3) I don't think you want Disabled = true.
>>
>> It’s the default. When you run `launchctl load -w` it overrides it to false in
>> its database. I’m fine to have it be less opaque, though.
>
> Yes, AFAICT it’s conventional to specify Disabled=true in a launchd plist and
> use launchctl to enable the item.
Yup, macports also has Disabled=true in the launchd items they install.
best regards,
Florian Pflug