Thread: Updated macOS start scripts
The stuff in contrib/start-scripts/osx/ does not, as far as I know,
work at all on any recent release of macOS, because SystemStarter
is long gone. I propose replacing it with the attached, which
I've tested on current-vintage Macs.
If anyone's interested in reviewing this, I'll stick it into the
next commitfest.
regards, tom lane
diff --git a/contrib/start-scripts/macos/README b/contrib/start-scripts/macos/README
index ...c4f2d9a .
*** a/contrib/start-scripts/macos/README
--- b/contrib/start-scripts/macos/README
***************
*** 0 ****
--- 1,24 ----
+ To make macOS automatically launch your PostgreSQL server at system start,
+ do the following:
+
+ 1. Edit the postgres-wrapper.sh script and adjust the file path
+ variables at its start to reflect where you have installed Postgres,
+ if that's not /usr/local/pgsql.
+
+ 2. Copy the modified postgres-wrapper.sh script into some suitable
+ installation directory. It can be, but doesn't have to be, where
+ you keep the Postgres executables themselves.
+
+ 3. Edit the org.postgresql.postgres.plist file and adjust its path
+ for postgres-wrapper.sh to match what you did in step 2. Also,
+ if you plan to run the Postgres server under some user name other
+ than "postgres", adjust the UserName parameter value for that.
+
+ 4. Copy the modified org.postgresql.postgres.plist file into
+ /Library/LaunchDaemons/. You must do this as root:
+ sudo cp org.postgresql.postgres.plist /Library/LaunchDaemons
+ because the file will be ignored if it is not root-owned.
+
+ At this point a reboot should launch the server. But if you want
+ to test it without rebooting, you can do
+ sudo launchctl load /Library/LaunchDaemons/org.postgresql.postgres.plist
diff --git a/contrib/start-scripts/macos/org.postgresql.postgres.plist
b/contrib/start-scripts/macos/org.postgresql.postgres.plist
index ...fdbd74f .
*** a/contrib/start-scripts/macos/org.postgresql.postgres.plist
--- b/contrib/start-scripts/macos/org.postgresql.postgres.plist
***************
*** 0 ****
--- 1,17 ----
+ <?xml version="1.0" encoding="UTF-8"?>
+ <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+ <plist version="1.0">
+ <dict>
+ <key>Label</key>
+ <string>org.postgresql.postgres</string>
+ <key>ProgramArguments</key>
+ <array>
+ <string>/bin/sh</string>
+ <string>/usr/local/pgsql/bin/postgres-wrapper.sh</string>
+ </array>
+ <key>UserName</key>
+ <string>postgres</string>
+ <key>KeepAlive</key>
+ <true/>
+ </dict>
+ </plist>
diff --git a/contrib/start-scripts/macos/postgres-wrapper.sh b/contrib/start-scripts/macos/postgres-wrapper.sh
index ...3a4ebda .
*** a/contrib/start-scripts/macos/postgres-wrapper.sh
--- b/contrib/start-scripts/macos/postgres-wrapper.sh
***************
*** 0 ****
--- 1,25 ----
+ #!/bin/sh
+
+ # PostgreSQL server start script (launched by org.postgresql.postgres.plist)
+
+ # edit these as needed:
+
+ # directory containing postgres executable:
+ PGBINDIR="/usr/local/pgsql/bin"
+ # data directory:
+ PGDATA="/usr/local/pgsql/data"
+ # file to receive postmaster's initial log messages:
+ PGLOGFILE="${PGDATA}/pgstart.log"
+
+ # (it's recommendable to enable the Postgres logging_collector feature
+ # so that PGLOGFILE doesn't grow without bound)
+
+
+ # set umask to ensure PGLOGFILE is not created world-readable
+ umask 077
+
+ # wait for networking to be up (else server may not bind to desired ports)
+ /usr/sbin/ipconfig waitall
+
+ # and launch the server
+ exec "$PGBINDIR"/postgres -D "$PGDATA" >>"$PGLOGFILE" 2>&1
> On Nov 15, 2017, at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The stuff in contrib/start-scripts/osx/ does not, as far as I know, > work at all on any recent release of macOS, because SystemStarter > is long gone. I propose replacing it with the attached, which > I've tested on current-vintage Macs. > > If anyone's interested in reviewing this, I'll stick it into the > next commitfest. Sure, I'll take a look. mark
> On Nov 15, 2017, at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The stuff in contrib/start-scripts/osx/ does not, as far as I know, > work at all on any recent release of macOS, because SystemStarter > is long gone. I propose replacing it with the attached, which > I've tested on current-vintage Macs. > I tested the presence of SystemStarter, which the old implementation uses, and launchd and launchctl, which your new implementation uses, on a couple of my mac laptops: OS X 10.11.6 SystemStarter - not installed launchd - installed launchctl - installed OS X 10.6.8 SystemStarter - installed launchd - installed launchctl - installed According to Wikipedia: "SystemStarter appears to have been removed from OS X 10.10 and later (reference needed)." and "In Mac OS X v10.4, it was deprecated in favor of launchd" Overall, I think supporting 10.10 and greater is more relevant than continuing to support 10.4 and earlier, though I suppose someone could argue for keeping both in side-by-side files with the README directing users which to use for whichever version of OS X they happen to be running. It's of no consequence to me, since my oldest mac is running 10.6.8, but somebody from the museum of old macs might feel differently. mark
Mark Dilger <hornschnorter@gmail.com> writes:
>> On Nov 15, 2017, at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The stuff in contrib/start-scripts/osx/ does not, as far as I know,
>> work at all on any recent release of macOS, because SystemStarter
>> is long gone. I propose replacing it with the attached, which
>> I've tested on current-vintage Macs.
> Overall, I think supporting 10.10 and greater is more relevant than continuing
> to support 10.4 and earlier, though I suppose someone could argue for
> keeping both in side-by-side files with the README directing users which to
> use for whichever version of OS X they happen to be running. It's of no
> consequence to me, since my oldest mac is running 10.6.8, but somebody
> from the museum of old macs might feel differently.
Well, we have no buildfarm coverage before 10.4, so to my mind those
releases are desupported already. In practice I wonder whether anyone
is really running PG on such old releases anyway. Certainly I wouldn't
think they'd be making new PG installations on machines that old.
regards, tom lane
> On Nov 15, 2017, at 11:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: >>> On Nov 15, 2017, at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> The stuff in contrib/start-scripts/osx/ does not, as far as I know, >>> work at all on any recent release of macOS, because SystemStarter >>> is long gone. I propose replacing it with the attached, which >>> I've tested on current-vintage Macs. > >> Overall, I think supporting 10.10 and greater is more relevant than continuing >> to support 10.4 and earlier, though I suppose someone could argue for >> keeping both in side-by-side files with the README directing users which to >> use for whichever version of OS X they happen to be running. It's of no >> consequence to me, since my oldest mac is running 10.6.8, but somebody >> from the museum of old macs might feel differently. > > Well, we have no buildfarm coverage before 10.4, so to my mind those > releases are desupported already. In practice I wonder whether anyone > is really running PG on such old releases anyway. Certainly I wouldn't > think they'd be making new PG installations on machines that old. I have tested this on 10.11.6. I had no trouble following the instructions in the README and everything worked as described. As far as I can tell, this patch has not yet been submitted to any commitfest. I would mark it Read for Committer. mark
Mark Dilger <hornschnorter@gmail.com> writes:
> I have tested this on 10.11.6. I had no trouble following the instructions
> in the README and everything worked as described.
> As far as I can tell, this patch has not yet been submitted to any commitfest.
> I would mark it Read for Committer.
Thanks for reviewing! Since you already did review it, I think we can
probably skip the CF paperwork and just push it.
One thing that needs to be figured out is what to do with the old osx
scripts. My inclination is to remove that subdirectory in HEAD.
However, I'd like to also stick these new scripts into the supported
back branches, since the problem is just as real for any back branch
as it is for v11. What I propose for the back branches is to add
contrib/start-scripts/macos/ alongside .../osx/, keeping the latter,
but adjust its README to note that those scripts are only for pre-10.10
versions of macOS.
regards, tom lane
> On Nov 15, 2017, at 1:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: >> I have tested this on 10.11.6. I had no trouble following the instructions >> in the README and everything worked as described. >> As far as I can tell, this patch has not yet been submitted to any commitfest. >> I would mark it Read for Committer. > > Thanks for reviewing! Since you already did review it, I think we can > probably skip the CF paperwork and just push it. > > One thing that needs to be figured out is what to do with the old osx > scripts. My inclination is to remove that subdirectory in HEAD. > However, I'd like to also stick these new scripts into the supported > back branches, since the problem is just as real for any back branch > as it is for v11. What I propose for the back branches is to add > contrib/start-scripts/macos/ alongside .../osx/, keeping the latter, > but adjust its README to note that those scripts are only for pre-10.10 > versions of macOS. I am reasonably content with your earlier idea of not keeping support for ancient versions of OS X, but if you want to do what you describe above, I'd be happy to review that on my 10.6 box to verify that everything works at least that far back. I don't have access to relevant, pre-10.4 machines. mark
Mark Dilger <hornschnorter@gmail.com> writes:
> I am reasonably content with your earlier idea of not keeping support
> for ancient versions of OS X, but if you want to do what you describe
> above, I'd be happy to review that on my 10.6 box to verify that
> everything works at least that far back. I don't have access to relevant,
> pre-10.4 machines.
IIRC, I already did test it on 10.6.8, but no harm in your double
checking.
regards, tom lane
> On Nov 15, 2017, at 12:02 PM, Mark Dilger <hornschnorter@gmail.com> wrote: > > >> On Nov 15, 2017, at 11:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnorter@gmail.com> writes: >>>> On Nov 15, 2017, at 8:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> The stuff in contrib/start-scripts/osx/ does not, as far as I know, >>>> work at all on any recent release of macOS, because SystemStarter >>>> is long gone. I propose replacing it with the attached, which >>>> I've tested on current-vintage Macs. >> >>> Overall, I think supporting 10.10 and greater is more relevant than continuing >>> to support 10.4 and earlier, though I suppose someone could argue for >>> keeping both in side-by-side files with the README directing users which to >>> use for whichever version of OS X they happen to be running. It's of no >>> consequence to me, since my oldest mac is running 10.6.8, but somebody >>> from the museum of old macs might feel differently. >> >> Well, we have no buildfarm coverage before 10.4, so to my mind those >> releases are desupported already. In practice I wonder whether anyone >> is really running PG on such old releases anyway. Certainly I wouldn't >> think they'd be making new PG installations on machines that old. > > I have tested this on 10.11.6. I had no trouble following the instructions > in the README and everything worked as described. > > As far as I can tell, this patch has not yet been submitted to any commitfest. > I would mark it Read for Committer. Upon further review, I have noticed that `pg_ctl stop` does not work once the org.postgresql.postgres service has been started. I was trying to stop, reinstall and re-initdb and restart postgres and this service was a pita. I had to go back to your osx.patch to remind myself what I had done and only then could I stop the service and continue my work. Is there any way this patch could be improved to work nicely with pg_ctl? It seems that `pg_ctl stop` indeed stops the postgres process, but the system launches a new one so quickly that pg_ctl thinks the service has not stopped, and it just waits forever (or until it times out, depending on your settings). If nothing else, the instructions in the patch about how to turn this feature on should have big warning flags about how pg_ctl won't work once you do this. mark
Mark Dilger <hornschnorter@gmail.com> writes:
> Upon further review, I have noticed that `pg_ctl stop` does not work once
> the org.postgresql.postgres service has been started. I was trying to stop,
> reinstall and re-initdb and restart postgres and this service was a pita. I had
> to go back to your osx.patch to remind myself what I had done and only then
> could I stop the service and continue my work.
> Is there any way this patch could be improved to work nicely with pg_ctl? It
> seems that `pg_ctl stop` indeed stops the postgres process, but the system
> launches a new one so quickly that pg_ctl thinks the service has not stopped,
> and it just waits forever (or until it times out, depending on your settings).
Hmm. Maybe we should have the plist file set KeepAlive to false not true?
This would mean you'd need manual action to restart a failed postmaster,
but that probably comes with the territory --- I do not see how we'd
teach launchd the difference between a "failed" postmaster and a manually
shut down one.
I think the normal way to stop/restart a launchd service is to use
"launchctl unload/load" ... we'd need to see how that interacts with
using pg_ctl. Some documentation might be needed in any case.
regards, tom lane
> On Nov 28, 2017, at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnorter@gmail.com> writes: >> Upon further review, I have noticed that `pg_ctl stop` does not work once >> the org.postgresql.postgres service has been started. I was trying to stop, >> reinstall and re-initdb and restart postgres and this service was a pita. I had >> to go back to your osx.patch to remind myself what I had done and only then >> could I stop the service and continue my work. > >> Is there any way this patch could be improved to work nicely with pg_ctl? It >> seems that `pg_ctl stop` indeed stops the postgres process, but the system >> launches a new one so quickly that pg_ctl thinks the service has not stopped, >> and it just waits forever (or until it times out, depending on your settings). > > Hmm. Maybe we should have the plist file set KeepAlive to false not true? > This would mean you'd need manual action to restart a failed postmaster, > but that probably comes with the territory --- I do not see how we'd > teach launchd the difference between a "failed" postmaster and a manually > shut down one. Setting KeepAlive to false does more than you probably want it to; it also causes the service not to start on boot nor on load. After setting this to false, I tried a reboot and the service was not started. > > I think the normal way to stop/restart a launchd service is to use > "launchctl unload/load" ... we'd need to see how that interacts with > using pg_ctl. Some documentation might be needed in any case. "launchctl load" won't do it. You need to use sudo launchctl start org.postgresql.postgres and sudo launchctl stop org.postgresql.postgres to get the behavior you are looking for. Note that start/stop take the name of the service, and load/unload take the name of the file. They're different, though related. I think anybody who uses launchctl on mac should already know what it does. I'm not too concerned about that. I think the hazard is that somebody who does not normally use launchctl on mac, but who reads through the postgres contrib/start-scripts directory, will follow the instructions in this patch and form a false expectation about what will result from configuring their mac laptop this way. Of course, you could make pg_ctl know how to interact with launchctl if you like. That seems quite hard, and I am not volunteering.... mark
Mark Dilger <hornschnorter@gmail.com> writes:
>> On Nov 28, 2017, at 11:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm. Maybe we should have the plist file set KeepAlive to false not true?
>> This would mean you'd need manual action to restart a failed postmaster,
>> but that probably comes with the territory --- I do not see how we'd
>> teach launchd the difference between a "failed" postmaster and a manually
>> shut down one.
> Setting KeepAlive to false does more than you probably want it to; it also
> causes the service not to start on boot nor on load. After setting this to
> false, I tried a reboot and the service was not started.
I don't feel like digging in Apple's docs right now, but surely there's
some option that will make it start the service on boot, but not restart
it if it quits later?
> Of course, you could make pg_ctl know how to interact with launchctl if you
> like. That seems quite hard, and I am not volunteering....
Seems like a nonstarter to me --- for one thing, how would pg_ctl know to
do that rather than its normal thing? And where would it get the service
name? And how's it gonna do that at all if not superuser?
regards, tom lane
On 11/28/17 14:07, Mark Dilger wrote: > Upon further review, I have noticed that `pg_ctl stop` does not work once > the org.postgresql.postgres service has been started. I was trying to stop, > reinstall and re-initdb and restart postgres and this service was a pita. I had > to go back to your osx.patch to remind myself what I had done and only then > could I stop the service and continue my work. But isn't that the point? If you use this setup, you are supposed to use launchctl to control the service, not pg_ctl. The same applies to, say, a systemd setup. If you are using a process manager, then trying to control the process outside of that process manager isn't going to work well. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Nov 28, 2017, at 1:22 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 11/28/17 14:07, Mark Dilger wrote: >> Upon further review, I have noticed that `pg_ctl stop` does not work once >> the org.postgresql.postgres service has been started. I was trying to stop, >> reinstall and re-initdb and restart postgres and this service was a pita. I had >> to go back to your osx.patch to remind myself what I had done and only then >> could I stop the service and continue my work. > > But isn't that the point? If you use this setup, you are supposed to > use launchctl to control the service, not pg_ctl. The same applies to, > say, a systemd setup. If you are using a process manager, then trying > to control the process outside of that process manager isn't going to > work well. Right, and I said something similar below: "I think anybody who uses launchctl on mac should already know what it does. I'm not too concerned about that. I think the hazard is that somebody who does not normally use launchctl on mac, but who reads through the postgres contrib/start-scripts directory, will follow the instructions in this patch and form a false expectation about what will result from configuring their mac laptop this way." I'm just saying the patch needs an update to the documentation to make this clear to users. mark