Re: Daniel Kahn Gillmor 2014-03-04 <[email protected]> > >> 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 [email protected] 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 already. > 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. Christoph -- [email protected] | http://www.df7cb.de/
signature.asc
Description: Digital signature
_______________________________________________ Pkg-postgresql-public mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public
