On Mon, 07.07.14 14:48, Pavel Raiskup (praiskup(a)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(a)redhat.com) wrote:
> > $ 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.
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 +
> I'd always advise against inventing addition configuration
> 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
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
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
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:
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
systemctl disable postgresql(a)foobar.service
systemctl start postgresql(a)foobar.service
systemctl stop postgresql(a)foobar.service
This way you need no hack environment variable files or settings or
anything, everything is just natural with native configuration
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
in this regard is (because there are some convenience scripts trying to
automatize usual admin's tasks - and these are dependant on systemd's
* Automatic way of exporting service's environment. Something like:
$ systemctl environment postgresql.service
The 'systemctl show -p Environment' does not work for us, because it
does not expand contents of EnvironmentFile :(. Also white-space
What's the usecase? (not really against this, just want to hear the
* I feel that you try to "standardize" the place where
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 Poettering, Red Hat