Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On 2014-07-15 08:52, Ian Stakenvicius wrote: > On 15/07/14 07:36 AM, Pacho Ramos wrote: > > El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: > > [...] > >> To alleviate this I needed to run "systemd-tmpfiles --create". > >> This was non-obvious to me. Sounds like a packaging issue that I > >> need to do it in the first place? > > > > It's: https://bugs.gentoo.org/show_bug.cgi?id=462118 > > > > The problem is that it's not clear to us how to make it > > automatically without needing to call it manually from every ebuild > > installing a tmpfiles.d file :( > > > > > > Wasn't there a plan to make an eclass helper to process tmpfiles.d > files that get installed, during pkg_postinst ? > > ...and now that I think about it, did I say that I was going to write it? > There's a bit more to it, as well. 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. I really don't want to get into an OpenRC versus systemd flame-war, but I really hate the systemd offering we have for PostgreSQL. It's dumb and I recommend against using it. I haven't used systemd and do not plan on using it until it actually fixes a problem that's non-trivial, which is most likely never for me. So, if any of you would like to improve our systemd offering, it'd be welcomed enthusiastically. -- Mr. Aaron W. Swenson Gentoo Linux Developer PostgreSQL Herd Bull Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 signature.asc Description: Digital signature
[gentoo-dev] new global use flag: opus
It's time to give opus its own global USE flag. 15 ebuilds use it locally for the same thing, and I've got another ebuild in the works to add it. Current usage: local:opus:media-libs/mediastreamer: Enable opus codec support local:opus:media-plugins/gst-plugins-meta: Enable Opus audio codec support local:opus:media-sound/asunder: Support for creation of Opus files local:opus:media-sound/cmus: enable support for media-libs/opusfile local:opus:media-sound/darkice: Enable Opus audio codec support local:opus:media-sound/easytag: Enable support for media-libs/opus and media-libs/opusfile (opus audio codec) local:opus:media-sound/kwave: Enable Opus audio codec support local:opus:media-sound/mangler: Codec specialized for speech over the internet local:opus:media-sound/mpd: Enable Opus codec support local:opus:media-sound/qmmp: Enable the opus plugin local:opus:media-sound/soundconverter: Enable Opus audio codec support local:opus:media-video/ffmpeg: Adds (decoding) support for the Opus codec via media-libs/opus. local:opus:media-video/libav: Use the external opus library for encoding and decoding. local:opus:media-video/vlc: Support opus decoding via libopus. local:opus:virtual/ffmpeg: Use the external opus library for encoding and decoding. New description: "Add support for the Opus audio codec" I'll add it into the tree in a few days if no-one objects. Thanks, Steve
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson 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).
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.
Rich
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On Fri, Aug 22, 2014 at 1:07 PM, Rich Freeman wrote:
> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson
> 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
Re: [gentoo-dev] systemd + postgresql is non-obvious to me
On Fri, Aug 22, 2014 at 2:07 PM, Rich Freeman wrote:
> On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson
> 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.
>
Personally, I prefer the thing to stop within a reasonable time period
when I tell it to stop. Waiting around for the remaining connections
to magically die (smart mode) is just tedious.
