Re: Patch: Add launchd Support

On Oct 20, 2014, at 5:03 PM, David E. Wheeler <david@justatheory.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
ideawhat that means. 

I think the idea of OnDemand is for launchd items to act a bit like inetd does: launchd creates the listening socket
(ormach port or file-change notification) on the port specified in the plist, and only starts the process when someone
triesto 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
wouldno longer be specifiable in postgres’ config, etc) and I’m skeptical that it’d be worth the work without a more
concretemotivation. 

Apple has published their changes to Postgres (since they ship it in recent versions of OSX) here, fwiw, including the
launchdplist 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
thatwill 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,
whichinvokes 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
interfacebeing up and having IPv4 or IPv6 addresses assigned to them.  If false, the job will be kept alive in the
inversecondition. 

On the other hand, it’s not unreasonable to have postgres running on a machine with only a loopback interface,
dependingon the use. 

> We might be able to put something in LaunchEvents that gets it to fire when the network launches, but documentation
ishella 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’srough 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
lessopaque, 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.