On Oct 20, 2014, at 5:03 PM, David E. Wheeler <da...@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 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
