[Pkg-postgresql-public] systemd support

Christoph Berg myon at debian.org
Wed Mar 5 09:50:35 UTC 2014

Re: Daniel Kahn Gillmor 2014-03-04 <531641AA.7040205 at fifthhorseman.net>
> >> To work, you also need the pg_ctlcluster version from HEAD.
> >> pg_ctlcluster now invokes postgres directly so it runs in foreground
> >> instead of daemonizing with pg_ctl - this seems more like the systemd
> >> way to do it.
> > 
> > This is going to have to be optional, isn't it?  I know that I'm
> > frequently running pg_ctlcluster myself, and aren't we going to need to
> > support kfreebsd with the traditional init system?

The init script won't be going away, and I don't plan to do any
changes that would change the traditional utilities.

However, if running in systemd, the "Restart=on-failure" in
postgresql at .service currently prevents most manual messing with the
cluster; systemd restarts it so quickly that "pg_dropcluster 9.3 main
--stop" doesn't work.

When working as root, we could probably reroute all manual
pg_ctlcluster calls through systemd to call pg_ctlcluster again, but
it's been a nice feature that all the commands could also be run from
postgres (or whatever the cluster owner is). That needs more thinking.

pg_ctlcluster stop doesn't work because systemd thinks postgres exited
with status 2. I'm getting status 0 when running on the console.
Possibly 2 is SIGINT which is used by -m fast shutdowns. (That'd be a
weird log message by systemd.) If that's the case, SIGINT should be
added to the "ok to exit on that signal" list in the unit file.

> can't we let the sysvinit initscript (or the moral equivalent for other
> non-supervising init systems) use start-stop-daemon --background instead
> of trucking that code around in pg_ctlcluster?  kFreeBSD'ers aren't
> necessarily going to use sysvinit anyway (e.g. i've run kFreeBSD with
> runit as pid 1, whose scripts would definitely prefer Christoph's
> proposed non-daemonizing pg_cltcluster semantics).

The non-daemonizing part is pg_ctlcluster --foreground, so that's
usable with any init system. There are two differences between bg and
fg operation now: 1) it logs to stderr 2) it doesn't read pg_ctl.conf.

Adding code to (optionally) point logging to /var/log/postgresql
wouldn't be too hard. Maybe --log=stderr|file ?

pg_ctl.conf isn't much of an issue, afaict the only option people put
there is -c (enable coredumps), there's probably some native systemd
alternative for it.

I wouldn't want to use start-stop-daemon --background because it's a
hack for programs that do not daemonize, and pg_ctl does that job

> if you're running it by hand yourself and you really don't want it to
> stay foregrounded, you have a whole slew of other options.  (though i
> like keeping my personal daemons foregrounded, personally)
> have you looked at all into the idea of a socket-activated postgresql
> for those initsystems that can handle socket activation?

I think it would be a nice idea, but would that work with PostgreSQL?
My impression was that it needs a daemon that takes connections on
stdin instead of opening a socket itself.

cb at df7cb.de | http://www.df7cb.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20140305/337f5038/attachment.sig>

More information about the Pkg-postgresql-public mailing list