On Fri, Aug 22, 2014 at 1:07 PM, Rich Freeman <ri...@gentoo.org> wrote:
> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson <titanof...@gentoo.org>
> wrote:
>> On the whole, I'm displeased with the systemd alternative for
>> controlling PostgreSQL. It's significantly hampered and doesn't allow
>> as much flexibility as the initscript. The major issue being trying to
>> nicely shut down the server instead of jumping straight to murder.
>>
>
> It looks like the package installs a service file provided by
> upstream, so you might want to direct your complaint there unless it
> really is a systemd limitation.
>
> Checking the latest version in portage it calls:
> ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
> ${DATA_DIR} -s -m fast
>
> I'm no postresql expert, but according to the manpage that should
> bring the server to a screeching, but still controlled, halt. Perhaps
> you would prefer setting it to -m smart instead of -m fast.
>
> If so override it in /etc/systemd/system. I generally recommend using
> drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
> will override the existing value, or simply cause systemd to run both
> commands (which means that whichever runs first will control how it
> stops).
It's the same as with ExecStart=; it gets added to a list, and all of
them are executed in the same order as they appear in the unit file.
In a drop-in, you can reset the list like this:
ExecStop=
ExecStop=new_and_only_command_to_be_executed
> Systemd shouldn't begin killing processes without mercy until the
> process invoked in ExecStop terminates, so it should not terminate
> until the process has finished graceful shutdown.
If ExecStop= wasn't specified, systemd would immediaely kill all the
service processes; from [1]: "If this option [ExecStop] is not
specified, the process is terminated immediately when service stop is
requested", which kinda sounds like "jumping straight to murder."
That the upstream unit file is configured otherwise, shows that
PostgreSQL upstream itself thinks that's a bad idea. No fault on
systemd's part.
Regards.
[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México
