PostgreSQL systemd config scheme change

[Lennart Poettering]

On Mon, 07.07.14 14:48, Pavel Raiskup (praiskup at redhat.com) wrote:

> 
> On Friday 04 of July 2014 00:09:03 Lennart Poettering wrote:
> > On Mon, 23.06.14 16:23, Pavel Raiskup (praiskup at redhat.com) wrote:
> > >   $ cat /etc/postgresql/postgresql at com_example
> > >   PGDATA=/some/path/pg/com_example
> > >   PGPORT=@SOMEPORT@
> > >   $ systemctl start postgresql at 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.
> 
> Kind of - but not so "pure" configuration files because we can not mark
> them %config based on packaging guildelines.

Well, I am not sure what the benefit would be, but you could %config +
%ghost them.

> > I'd always advise against inventing addition configuration files that
> > are neither the daemons own, nor systemd's.
> 
> I hope we can call this as a systemd's configuration, or no?  It sounds
> like EnvironmentFile is also starting to be deprecated, is it so?

No. Things you pull in via EnvironmentFile= are not systemd's
configuration file. They are something you defined.

> The first neat benefit about this is that the configuration file may be
> sourced by any shell script.  The second benefit is that user doesn't need
> to bother with so long directory names:
> 
>   $ cat /etc/systemd/system/postgresql at com.example.d/redef_sth.conf
>   [service]
>   Environ=PGDATA=_Pathname_without_spaces_

Honestly, the right fix of this is to simply turn these two env vars
into proper, native postgresql configuration directives, and then not invent
anything new. Actually, aren't they proper, native postgresql
configuration directives anyway? i mean, there's the "port" setting in
postgresql.conf if I google for it. Seems to have something for PGDATA
as well. 

With that in place you could just make this a template service that
simply invokes postgresql with a different configuration file derived
from the instance name:

postgresql at .service:

        [Service]
        ExecStart=/usr/sbin/postgres -c config_file=/etc/postgres/postgresql-%i.conf

Then, people can just place their own postgresql.conf file with their
individual settings in /etc/potsgres/postgresql-foobar.conf and simply
enable, disable, start stop the instnace with that configuration file with:

systemctl enable postgresql at foobar.service
systemctl disable postgresql at foobar.service
systemctl start postgresql at foobar.service
systemctl stop postgresql at foobar.service

This way you need no hack environment variable files or settings or
anything, everything is just natural with native configuration
directives.

And if you are concerenced that this way you lose rpm control over the
config files: postgersql actually knows an "include" directive...

> Little off-topic, but imo worth saying.  What I think we miss in systemd
> in this regard is (because there are some convenience scripts trying to
> automatize usual admin's tasks - and these are dependant on systemd's
> configuration):
> 
>   * Automatic way of exporting service's environment.  Something like:
> 
>     $ systemctl environment postgresql.service
>     PGDATA=/path/to/a/data/dir
>     PGPORT=5433
> 
>     The 'systemctl show -p Environment' does not work for us, because it
>     does not expand contents of EnvironmentFile :(.  Also white-space
>     problems ..

What's the usecase? (not really against this, just want to hear the
precise usecase)

>   * I feel that you try to "standardize" the place where services are
>     configured.  What about to have some "standard" location with
>     files in EnvironementFile= format.  Could we then mark those as
>     %config in spec file?

No. This is not sysvinit. Service files are something admins should
totally edit all the time. They should copy the files, or use drop-ins,
or use "systemctl set-property" or the bus apis, but they are intended
to be something the admin changes if needed. For example, if the admin
wants to limit postgersql's memory usage to 2G or bind it to some CPU,
he should do that. We should not invent a second layer of configuration
files, that allow everything to set up multiple different ways...

Lennart

-- 
Lennart Poettering, Red Hat