On Monday 07 of July 2014 15:57:30 Lennart Poettering wrote:
On Mon, 07.07.14 14:48, Pavel Raiskup (praiskup(a)redhat.com) wrote:
> > 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.
I defined the _place_ where the systemd's configuration is placed. Truth.
> 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(a)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.
How I understand the PostgreSQL intentions, its complete and extensive
configuration tends to be moved to database itself. So any other info
than PGDATA is not in our interest. Tom is in loop but I would guess
that standardizing path to file where PGDATA is configured is not
something worth specifying upstream..
You use PGDATA to init/upgrade/check database.. cross any platform. And
for multiple instances of PostgreSQL server you need to have easy way how
to specify PGDATA (which is our task now).
And, yes, one of my intentions is to move configuration of PGPORT into
postgresql.conf directly (which is quite easily possible).
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@.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(a)foobar.service
[...]
This way you need no hack environment variable files or settings or
anything, everything is just natural with native configuration
directives.
See above (this way I think it would be too against PG upstream).
> 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)
You can look e.g. at postgresql-setup script (in Fedora's
postgresql-server package). That script needs to know the PGDATA place -
and currently we need to parse the 'show -p Environment' output.
Pavel