On Mon, 23.06.14 16:23, Pavel Raiskup (praiskup@xxxxxxxxxx) wrote: > Hello all, > > there is currently not so much things to configure in PostgreSQL from > systemd's service point of view (not taking postgresql.conf into account), > concretely, we configure PGPORT and PGDATA, from which the later is > important (and often re-configured to point e.g. to some dedicated mount > point, etc.). That tells systemd's unit file where it should start > PostgreSQL server from. > > What does not seem to be quite 100% OK is that, when user wants to change > PGDATA, we instruct him to make a separate service file: > > $ cat /etc/systemd/system/postgresql.service > .include /usr/lib/systemd/system/postgresql.service Please migrate away from ".include", please use .d/ drop-ins instead. We kinda are deprecating ".include", only support it for compatibility instead. > [Service] > Environment=PGDATA=/some/other/place/than/default > > This works OK -- but the problem is that it is quite too much for just > changing one simple directory path. > > What seems to be better approach is to have real configuration file, such one > for which '$ rpm -qc postgresql-server' would not be quiet. Lets say: > > $ cat /etc/postgresql/postgresql > PGDATA=/some/other/place/than/default > > With some additional packager's work, that allows us to do yet another > configuration easily - and that is multiple PostgreSQL running on one > single machine (on different ports or IPs). The only thing would be to > create yet another file: > > $ cat /etc/postgresql/postgresql@com_example > PGDATA=/some/path/pg/com_example > PGPORT=@SOMEPORT@ > $ systemctl start postgresql@com_example > > Would you see something bad on that approach (please, take into account that > we would not stop supporting the old way, we just want to make future > configuration easier and straight-forward). Unit files are configuration files. It's OK to copy unit files from /usr/lib/systemd/system into /etc/systemd/system and edit it there. I'd always advise against inventing addition configuration files that are neither the daemons own, nor systemd's. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
