Re: Patch: Add launchd Support - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Patch: Add launchd Support
Date
Msg-id 5454C107.4010309@gmx.net
Whole thread Raw
In response to Re: Patch: Add launchd Support  (Wim Lewis <wiml@omnigroup.com>)
List 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
thelaunchd 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
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.
 

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,
whichinvokes 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
interfacebeing up and having IPv4 or IPv6 addresses assigned to them.  If false, the job will be kept alive in the
inversecondition.
 

My launchd.plist man page says:
  NetworkState <boolean>  This key is no longer implemented as it never acted how most users
expected.




pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Let's drop two obsolete features which are bear-traps for novices
Next
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps