Please provide systemd unit file. Reproducible: Always
Created attachment 347598 [details, diff] postgresql-server-9.2.4-r1.ebuild.patch
Created attachment 347600 [details] postgresql.service
Created attachment 347602 [details] postgresql.tmpfilesd
Created attachment 347604 [details] postgresql.tmpfilesd Create dir in /run instead of /var/run
(In reply to comment #1) > Created attachment 347598 [details, diff] [details, diff] > postgresql-server-9.2.4-r1.ebuild.patch If you put postgresql.service and postgresql.tmpfilesd in postgresql-initscript-*.tbz2, then of course some changes should be made to this patch.
(In reply to comment #2) > Created attachment 347600 [details] > postgresql.service This file is a modified unit taken from fedora package. "postgresql-check-db-dir" is a script that checks that db is initialized and does not need an upgrade. I leave ExecStartPre commented for now.
I'll need a postgresql.service file that's suitable for pre-9.2 servers as well before I can include it in Portage.
Created attachment 354046 [details] postgresql.service This unit is suitable for all postgresql versions. I tested it with 8.4, 9.1 and 9.2. - fixed ExecStart, ExecStop and ExecReload options - added PIDFile option - uncommented ExecStartPre
Created attachment 354048 [details] postgresql-check-db-dir Script for ExecStartPre
Created attachment 354050 [details, diff] postgresql-server-9.2.4-r1.ebuild.patch - install postgresql-check-db-dir script - move sed commands in src_prepare()
(In reply to Alexander Tsoy from comment #9) > Created attachment 354048 [details] > postgresql-check-db-dir > > Script for ExecStartPre It is based on checkconfig() from init script.
Created attachment 354056 [details] postgresql-check-db-dir s/return/exit/
Created attachment 354132 [details] postgresql.service Drop PIDFile. Variables not allowed in this option and unit works fine whithout it.
Hmmm... sorry for messing all up. Maybe doing something wrong, but attached files doesn't work. Steps performed: 1. Copy ebuild of 9.2.4 to local overlay and rename to 9.2.4-r1; 2. download all files to "files" subfolder; 3. ebuild digest; 3. eix-update; 4. emerge -u postgresql-server; 5. emerge --config =dev-db/postgresql-server; Actual result: parmasse OhtarGentoo # systemctl start postgresql Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details. parmasse OhtarGentoo # journalctl -xn -- -- Unit postgresql.service has begun starting up. авг 03 02:17:28 parmasse systemd[24084]: Failed at step EXEC spawning /usr/bin/postgresql-@SLOT@-check-db-dir: No such file or directory -- Subject: Process /usr/bin/postgresql-@SLOT@-check-db-dir could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7 -- -- The process /usr/bin/postgresql-@SLOT@-check-db-dir could not be executed and failed. -- -- The error number returned while executing this process is 2. авг 03 02:17:28 parmasse systemd[1]: postgresql.service: control process exited, code=exited status=203 авг 03 02:17:28 parmasse systemd[1]: Failed to start PostgreSQL database server. -- Subject: Unit postgresql.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d -- -- Unit postgresql.service has failed. -- -- The result is failed. авг 03 02:17:28 parmasse systemd[1]: Unit postgresql.service entered failed state. However, the file exists: parmasse OhtarGentoo # ls -la /usr/bin/postgresql-9.2-check-db-dir -rwxr-xr-x 1 root root 1031 авг 3 02:15 /usr/bin/postgresql-9.2-check-db-dir What am I missing?
Damn, it's to late for gentoo-ing... Forgot mentioning, that applied patch for ebuild
(In reply to Constantine E. Kozlov from comment #14) > Hmmm... sorry for messing all up. > Maybe doing something wrong, but attached files doesn't work. > Steps performed: > 1. Copy ebuild of 9.2.4 to local overlay and rename to 9.2.4-r1; > 2. download all files to "files" subfolder; > 3. ebuild digest; > 3. eix-update; > 4. emerge -u postgresql-server; > 5. emerge --config =dev-db/postgresql-server; > > Actual result: > parmasse OhtarGentoo # systemctl start postgresql > Job for postgresql.service failed. See 'systemctl status postgresql.service' > and 'journalctl -xn' for details. > parmasse OhtarGentoo # journalctl -xn > -- > -- Unit postgresql.service has begun starting up. > авг 03 02:17:28 parmasse systemd[24084]: Failed at step EXEC spawning > /usr/bin/postgresql-@SLOT@-check-db-dir: No such file or directory > -- Subject: Process /usr/bin/postgresql-@SLOT@-check-db-dir could not be > executed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Documentation: > http://www.freedesktop.org/wiki/Software/systemd/catalog/ > 641257651c1b4ec9a8624d7a40a9e1e7 > -- > -- The process /usr/bin/postgresql-@SLOT@-check-db-dir could not be executed > and failed. > -- > -- The error number returned while executing this process is 2. > авг 03 02:17:28 parmasse systemd[1]: postgresql.service: control process > exited, code=exited status=203 > авг 03 02:17:28 parmasse systemd[1]: Failed to start PostgreSQL database > server. > -- Subject: Unit postgresql.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Documentation: > http://www.freedesktop.org/wiki/Software/systemd/catalog/ > be02cf6855d2428ba40df7e9d022f03d > -- > -- Unit postgresql.service has failed. > -- > -- The result is failed. > авг 03 02:17:28 parmasse systemd[1]: Unit postgresql.service entered failed > state. > > > However, the file exists: > parmasse OhtarGentoo # ls -la /usr/bin/postgresql-9.2-check-db-dir > -rwxr-xr-x 1 root root 1031 авг 3 02:15 /usr/bin/postgresql-9.2-check-db-dir > > > What am I missing? I start it with... systemctl start postgresql-9.2 It runs properly
(In reply to Emanuel Dávila from comment #16) > > I start it with... > > systemctl start postgresql-9.2 > > It runs properly Daaaamn... Sure, it's pretty fine. Before this, I tried to create such service manually from ARCHlinux forum, I succeed, but going here to post bug made me come to this page. So I just tried to start own broken service (postgresql.service) instead of this (postgresql-9.2.service). Anyway, still have question to this bugfix: How such service will be handled through eselect? As example, now 9.3 unmasked and it'll, therefore, install new such service. Yes, it will not be started automatically just after install, but isn't it possible to handle eselect-ed slot (eselect postgresql show) through service like just 'postgresql.service'? Sure, I can simply suggest such changed service and ebuild, but I dont know, does such changes needed - it wasn't made, and I'm pretty new to writing ebuilds, services and other to know, was this omitted accidentally or not.
(In reply to Constantine E. Kozlov from comment #17) > (In reply to Emanuel Dávila from comment #16) > > > > I start it with... > > > > systemctl start postgresql-9.2 > > > > It runs properly > > Daaaamn... Sure, it's pretty fine. Before this, I tried to create such > service manually from ARCHlinux forum, I succeed, but going here to post bug > made me come to this page. So I just tried to start own broken service > (postgresql.service) instead of this (postgresql-9.2.service). > > Anyway, still have question to this bugfix: > How such service will be handled through eselect? As example, now 9.3 > unmasked and it'll, therefore, install new such service. Yes, it will not be > started automatically just after install, but isn't it possible to handle > eselect-ed slot (eselect postgresql show) through service like just > 'postgresql.service'? > > Sure, I can simply suggest such changed service and ebuild, but I dont know, > does such changes needed - it wasn't made, and I'm pretty new to writing > ebuilds, services and other to know, was this omitted accidentally or not. 'postgresql-config' will not handle this. The service files will be installed with the slot appended and it is up to the administrator what they want the default to be.
@Aaron, will you take care of this? I can also commit the service files when I have time if you prefer :)
(In reply to Pacho Ramos from comment #19) > @Aaron, will you take care of this? I can also commit the service files when > I have time if you prefer :) I'm not terribly interested in systemd so I'm a bit suspect of all this, which is why I've been slow in adding this feature. It seems to be moving away from what users have expressed they wanted: Control through /etc/postgresql-${SLOT}/postgresql.conf. It doesn't look like there's a way to keep what we've been gaining in the initscripts with the systemd service file. Yes, I'll add this as it is...but it isn't a very good replacement for the existing initscripts.
(In reply to Aaron W. Swenson from comment #20) > (In reply to Pacho Ramos from comment #19) > > @Aaron, will you take care of this? I can also commit the service files when > > I have time if you prefer :) > > I'm not terribly interested in systemd so I'm a bit suspect of all this, > which is why I've been slow in adding this feature. > > It seems to be moving away from what users have expressed they wanted: > Control through /etc/postgresql-${SLOT}/postgresql.conf. It doesn't look > like there's a way to keep what we've been gaining in the initscripts with > the systemd service file. I don't see what do you mean. AFAICS the attached .service file actually uses all that mess. Though I don't understand why it's explicitly specifying the port. Unless I'm missing something, you are supposed to set the port via the config file. Does that have any disadvantages over the ugly -o '-p ...'?
(In reply to Michał Górny from comment #21) > (In reply to Aaron W. Swenson from comment #20) > > (In reply to Pacho Ramos from comment #19) > > > @Aaron, will you take care of this? I can also commit the service files when > > > I have time if you prefer :) > > > > I'm not terribly interested in systemd so I'm a bit suspect of all this, > > which is why I've been slow in adding this feature. > > > > It seems to be moving away from what users have expressed they wanted: > > Control through /etc/postgresql-${SLOT}/postgresql.conf. It doesn't look > > like there's a way to keep what we've been gaining in the initscripts with > > the systemd service file. > > I don't see what do you mean. AFAICS the attached .service file actually > uses all that mess. The service file is incapable of progressively attempting more aggressive means of stopping PostgreSQL. If I can be proven wrong here I'd be happier about this. > Though I don't understand why it's explicitly specifying the port. Unless > I'm missing something, you are supposed to set the port via the config file. > Does that have any disadvantages over the ugly -o '-p ...'? The PGPORT can be dropped, but the initscript pulls that from the config file if it's set. Not grabbing the port information leads to a longer wait on finding out that the server can't bind to a port. So, it's a convenience thing rather than a technical requirement. The start command for 9.2+ is a bit messy and can be simplified so that it's easier to read. Something I was planning to do anyway. Some of the mess is there because of legacy systems. I'll be removing some bits and pieces that would no longer be a concern after some time passes. Several users, though, have expressed repeatedly that they want postgresql.conf to control the server, and not have to edit /etc/conf.d/postgresql-${SLOT}. Specifically the port, socket directory, and the data directory. That's what we lose with the service file.
Almost ready [1] to commit to gentoo-x86. I can't test this, though, so if somebody would give it a go and make sure all the ebuilds are working as they should with systemd. [1] https://github.com/titanofold/titanofold-gentoo-x86/tree/master/dev-db/postgresql-server
(In reply to Aaron W. Swenson from comment #22) > The service file is incapable of progressively attempting more aggressive > means of stopping PostgreSQL. We can use multiple ExecStop commands in unit, something like this: ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m smart -t $NICE_TIMEOUT ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m fast -t $RUDE_TIMEOUT ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m immediate -t $FORCE_TIMEOUT I didn't test it yet. May be the first two commands should be prefixed with '-'. (In reply to Aaron W. Swenson from comment #22) > Several users, though, have expressed repeatedly that they want > postgresql.conf to control the server, and not have to edit > /etc/conf.d/postgresql-${SLOT}. Specifically the port, socket directory, and > the data directory. That's what we lose with the service file. I have a question about the data directory. Is it possible with pg_ctl? Seems pg_ctl expects that -D is pointing to the directory with pid file and probably postmaster.opts (${DATA_DIR}), so I have no idea how to define data directory only in postgresql.conf.
(In reply to Alexander Tsoy from comment #24) > (In reply to Aaron W. Swenson from comment #22) > > The service file is incapable of progressively attempting more aggressive > > means of stopping PostgreSQL. > > We can use multiple ExecStop commands in unit, something like this: > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > smart -t $NICE_TIMEOUT > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > fast -t $RUDE_TIMEOUT > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > immediate -t $FORCE_TIMEOUT > > I didn't test it yet. May be the first two commands should be prefixed with > '-'. If you could make that work, I'd be happy to commit it. In a properly working setup `pg_ctl stop ... immediate` should never be encountered, but `pg_ctl stop ... fast` might be regularly encountered because of long lived programs writing to the database, like rsyslog. > I have a question about the data directory. Is it possible with pg_ctl? > Seems pg_ctl expects that -D is pointing to the directory with pid file and > probably postmaster.opts (${DATA_DIR}), so I have no idea how to define data > directory only in postgresql.conf. -D is supposed to point at the directory containing either the database files or configuration files. Apparently this isn't documented for pg_ctl, but that is the way it works for 9.2 and later. However, we don't have the initscripts pulling the data directory from the configuration file anyway. (I thought it did, but I was mistaken.) Again, technically nothing prevents us from doing so now with 9.2 and later, but for simplicity we can wait until 9.1 and older reach end of life.
(In reply to Aaron W. Swenson from comment #25) > (In reply to Alexander Tsoy from comment #24) > > (In reply to Aaron W. Swenson from comment #22) > > > The service file is incapable of progressively attempting more aggressive > > > means of stopping PostgreSQL. > > > > We can use multiple ExecStop commands in unit, something like this: > > > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > smart -t $NICE_TIMEOUT > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > fast -t $RUDE_TIMEOUT > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > immediate -t $FORCE_TIMEOUT > > > > I didn't test it yet. May be the first two commands should be prefixed with > > '-'. > > If you could make that work, I'd be happy to commit it. In a properly > working setup `pg_ctl stop ... immediate` should never be encountered, but > `pg_ctl stop ... fast` might be regularly encountered because of long lived > programs writing to the database, like rsyslog. Or anyone for that matter since there seems to be quite a few followers on this now.
Did I miss something or is there a specific reason not to use service instances to refer to the different SLOTs? Instead of creating a specific unit file for each SLOT, a single file could be enough to address all instances. See also the unit for OpenVPN: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openvpn/files/openvpn.service?revision=1.1&view=markup This would allow to refer to different SLOTs like this: systemctl start postgresql-server@9.2 whereas "9.2" would replace %i in the unit file.
(In reply to Elias Probst from comment #27) > Did I miss something or is there a specific reason not to use service > instances to refer to the different SLOTs? > Instead of creating a specific unit file for each SLOT, a single file could > be enough to address all instances. > > See also the unit for OpenVPN: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openvpn/ > files/openvpn.service?revision=1.1&view=markup > > This would allow to refer to different SLOTs like this: > systemctl start postgresql-server@9.2 > whereas "9.2" would replace %i in the unit file. This is not good idea. Macros %I not available in ExecStart/ExecStop in path to binary. In addition to different versions of slots can support a variety of command line options. For exabple 8.4 support key -silent-mode=true, but 9.2 don't.
(In reply to Egor Y. Egorov from comment #28) > This is not good idea. Macros %I not available in ExecStart/ExecStop in path > to binary. Do you have any sources for this? I can't find anything related, all that I could find looks like this is not a problem. > In addition to different versions of slots can support a variety > of command line options. For exabple 8.4 support key -silent-mode=true, but > 9.2 don't. Why not use SLOT specific conf.d/ files for this?
(In reply to Elias Probst from comment #27) > Did I miss something or is there a specific reason not to use service > instances to refer to the different SLOTs? > Instead of creating a specific unit file for each SLOT, a single file could > be enough to address all instances. postgresql-server ebuild is slotted. Unit installed by each slot should have an unique name. > > See also the unit for OpenVPN: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openvpn/ > files/openvpn.service?revision=1.1&view=markup > > This would allow to refer to different SLOTs like this: > systemctl start postgresql-server@9.2 > whereas "9.2" would replace %i in the unit file. %i and other variables are not allowed in the path to command.
(In reply to Aaron W. Swenson from comment #26) > (In reply to Aaron W. Swenson from comment #25) > > (In reply to Alexander Tsoy from comment #24) > > > (In reply to Aaron W. Swenson from comment #22) > > > > The service file is incapable of progressively attempting more aggressive > > > > means of stopping PostgreSQL. > > > > > > We can use multiple ExecStop commands in unit, something like this: > > > > > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > > smart -t $NICE_TIMEOUT > > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > > fast -t $RUDE_TIMEOUT > > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > > immediate -t $FORCE_TIMEOUT > > > > > > I didn't test it yet. May be the first two commands should be prefixed with > > > '-'. > > > > If you could make that work, I'd be happy to commit it. In a properly > > working setup `pg_ctl stop ... immediate` should never be encountered, but > > `pg_ctl stop ... fast` might be regularly encountered because of long lived > > programs writing to the database, like rsyslog. > > Or anyone for that matter since there seems to be quite a few followers on > this now. Most likely I'll have no time to do this until next week. Also according to the recently published systemd/ebuild policy, using env variables in units is strongly discouraged. :( https://wiki.gentoo.org/wiki/Systemd/Ebuild_policy
(In reply to Elias Probst from comment #29) > Do you have any sources for this? I can't find anything related, all that I > could find looks like this is not a problem. The command line accepts "%" specifiers as described in systemd.unit(5). Note that the first argument of the command line (i.e. the program to execute) may not include specifiers. © man systemd.service
systemctl start won't let you start services with "@" in their name
(In reply to Pacho Ramos from comment #33) > systemctl start won't let you start services with "@" in their name Bleh, that is wrong, just tested :S
(In reply to Aaron W. Swenson from comment #25) > (In reply to Alexander Tsoy from comment #24) > > (In reply to Aaron W. Swenson from comment #22) > > > The service file is incapable of progressively attempting more aggressive > > > means of stopping PostgreSQL. > > > > We can use multiple ExecStop commands in unit, something like this: > > > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > smart -t $NICE_TIMEOUT > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > fast -t $RUDE_TIMEOUT > > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > immediate -t $FORCE_TIMEOUT > > > > I didn't test it yet. May be the first two commands should be prefixed with > > '-'. > > If you could make that work, I'd be happy to commit it. In a properly > working setup `pg_ctl stop ... immediate` should never be encountered, but > `pg_ctl stop ... fast` might be regularly encountered because of long lived > programs writing to the database, like rsyslog. This works: ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m smart -t $NICE_TIMEOUT ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m fast -t $RUDE_TIMEOUT "stop -m immediate" is not needed - systemd kills all remaining processes. Exit status of both commands is ignored, and I dislike this solution. IMHO if something goes wrong, unit must enter failing state, that is not happen if we ignore exit status. Moreover, if other services use postgres (like rsyslog), then they unit files should be customized with "After=postgresql-SLOT". This way they will be started after postgres and will be stopped before it.
(In reply to Alexander Tsoy from comment #35) > This works: > > ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > smart -t $NICE_TIMEOUT > ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > fast -t $RUDE_TIMEOUT > > "stop -m immediate" is not needed - systemd kills all remaining processes. > Exit status of both commands is ignored, and I dislike this solution. IMHO > if something goes wrong, unit must enter failing state, that is not happen > if we ignore exit status. Moreover, if other services use postgres (like > rsyslog), then they unit files should be customized with > "After=postgresql-SLOT". This way they will be started after postgres and > will be stopped before it. It would be good to keep "immediate" mode in there as an example, commented out of course, as there may be a time other than machine shutdown that PostgreSQL will need to be stopped. As for the command, couldn't we do: ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m smart -t $NICE_TIMEOUT || /usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m fast -t $RUDE_TIMEOUT Then we'd get an appropriate exit status, right?
(In reply to Aaron W. Swenson from comment #36) > (In reply to Alexander Tsoy from comment #35) > > This works: > > > > ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > smart -t $NICE_TIMEOUT > > ExecStop=-/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > > fast -t $RUDE_TIMEOUT > > > > "stop -m immediate" is not needed - systemd kills all remaining processes. > > Exit status of both commands is ignored, and I dislike this solution. IMHO > > if something goes wrong, unit must enter failing state, that is not happen > > if we ignore exit status. Moreover, if other services use postgres (like > > rsyslog), then they unit files should be customized with > > "After=postgresql-SLOT". This way they will be started after postgres and > > will be stopped before it. > > It would be good to keep "immediate" mode in there as an example, commented > out of course, as there may be a time other than machine shutdown that > PostgreSQL will need to be stopped. > > As for the command, couldn't we do: > ExecStop=/usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D ${DATA_DIR} -s -m > smart -t $NICE_TIMEOUT || /usr/lib/postgresql-@SLOT@/bin/pg_ctl stop -D > ${DATA_DIR} -s -m fast -t $RUDE_TIMEOUT > > Then we'd get an appropriate exit status, right? systemd doesn't support shell command lines. Following should work: ExecStop=/bin/sh -c "... || ..." but it's very ugly. :)
If you want to do conditional stuff in ExecStop, it might be best to create an external shell script and call that. You could even share it with the openrc script. However, given the behavior of postgres, the "smart" shutdown is the only one for which pg_ctl is actually needed. pg_ctl -m fast sends SIGINT to the master, which then sends SIGTERM to the children. systemd will automatically send SIGTERM to all processes in the cgroup if ExecStop times out, so that's pretty much the same end result. pg_ctl -m immediate sends SIGQUIT to the master, whereas the normal systemd fallback is SIGKILL. I'm not sure if you actually want to worry about this case.
Exherbo is doing the stop in this way: http://git.exherbo.org/arbor.git/tree/packages/dev-db/postgresql/files/systemd/9.2/postgresql.service
(In reply to Pacho Ramos from comment #39) > Exherbo is doing the stop in this way: > http://git.exherbo.org/arbor.git/tree/packages/dev-db/postgresql/files/ > systemd/9.2/postgresql.service This is the same idea, which Aaron proposed in comment 36. And imho "immediate" step is not needed here.
+*postgresql-server-9.2.5 (11 Oct 2013) +*postgresql-server-8.4.18 (11 Oct 2013) +*postgresql-server-9.1.10 (11 Oct 2013) +*postgresql-server-9.0.14 (11 Oct 2013) +*postgresql-server-9.3.1 (11 Oct 2013) + + 11 Oct 2013; Patrick Lauer <patrick@gentoo.org> + +postgresql-server-8.4.18.ebuild, +postgresql-server-9.0.14.ebuild, + +postgresql-server-9.1.10.ebuild, +postgresql-server-9.2.5.ebuild, + +postgresql-server-9.3.1.ebuild: + Bump This looks to include systemd unit files :O
*** Bug 491418 has been marked as a duplicate of this bug. ***
