Re: Patch: Add launchd Support

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Wim Lewis <wiml(at)omnigroup(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: Add launchd Support
Date: 2014-11-01 11:16:23
Message-ID: 5454C107.4010309@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/20/14 8:53 PM, Wim Lewis wrote:
> 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.

I have a file /System/Library/LaunchAgents/com.apple.postgres.plist that
uses the label com.apple.postgres instead.

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

Probably because it's apparently really difficult to do it in a
different 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.

My launchd.plist man page says:

NetworkState <boolean>
This key is no longer implemented as it never acted how most users
expected.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2014-11-01 11:19:32 Re: tracking commit timestamps
Previous Message Amit Langote 2014-11-01 11:14:46 Re: Let's drop two obsolete features which are bear-traps for novices