Re: Patch: Add launchd Support

On Oct 20, 2014, at 5:03 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> This another reason not to use KeepAlive, I guess. OnDemand is supposed to fire up a job only when it’s needed. No idea what that means.

I think the idea of OnDemand is for launchd items to act a bit like inetd does: launchd creates the listening socket (or mach port or file-change notification) on the port specified in the plist, and only starts the process when someone tries to connect to it. This might not be a terrible thing to support, but it would require more changes throughout postgres (postmaster would have to check in with launchd at start time to get the listen socket; ports and socket paths would no longer be specifiable in postgres’ config, etc) and I’m skeptical that it’d be worth the work without a more concrete motivation.

Apple has published their changes to Postgres (since they ship it in recent versions of OSX) here, fwiw, including the launchd plist they use: http://www.opensource.apple.com/source/PostgreSQL/

One thing I noticed is that Apple also used the label “org.postgres.postgres” for their launchd job. I don’t know if that will collide in some way with a second job with the same label. Launchctl load/unload takes a pathname, not a job label, so I don’t think it’d be a problem unless you actually do want to run both copies of postgres at the same time.

MacPorts also has a launchd job for their postgresql port, which invokes daemondo, which invokes a wrapper script, which invokes postgres. I’m not sure why they did it that way.

> 2) AFAICS, this .plist file doesn't do anything about launchd's habit of not waiting for the network to come up.

Have you experimented with this setting?:

<key>KeepAlive</key>
<dict><key>NetworkState</key><true/></dict>

The launchd.plist man page claims that if you set that key in the sub-dictionary:
> 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.

> 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.

>> (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.

> BTW, Mavericks has a comment that /etc/hostconfig is going away, but google isn't telling me what's replacing it…

I think that’s been “going away” for a decade now.