On 12/18/2015 04:00 PM, Michael Biebl wrote:
2015-12-09 20:46 GMT+01:00 Lennart Poettering <lenn...@poettering.net>:
On Wed, 09.12.15 18:27, Soumya Koduri (skod...@redhat.com) wrote:
Hi,
I have created a systemd.unit(nfs-ganesha.service) file as below :
[Unit]
After=nfs-ganesha-config.service
Requires=nfs-ganesha-config.service
....
[Service]
EnvironmentFile=-/run/sysconfig/ganesha
ExecStart=/usr/bin/ganesha.nfsd $OPTIONS ${EPOCH}
(But honestly, there's really no point in trying to dynamically
convert stuff into a file that is suitable for EnvironmentFile=. I
mean, if you want a shell script, then use a shell script, and invoke
that from the main daemon's ExecStart= line, and make it exec the real
daemon as last step. There's really no point in playing these
multi-service conversion games. Also /etc/sysconfig is a Redhatism
that should really go away, the whole concept is flawed. Adding a new
/run/sysconfig/ certainly makes that even worse.)
I probably should never have added EnvironmentFile= in the first
place. Packagers misunderstand that unit files are subject to admin
configuration and should be treated as such, and that spliting out
configuration of unit files into separate EnvironmentFiles= is a
really non-sensical game of unnecessary indirection.
I do think that overriding the complete ExecStart= line is usually
suboptimal and not what you want if you just want to pass additional
options to the daemon.
Maybe a good middle ground / recommendation for such daemons would be,
to ship a line
ExecStart=/usr/sbin/foobard $OPTS
and then tell admin to use systemctl edit
[Unit]
Environment=OPTS=-baz
bonus points if we could standardise the $OPTS var name across daemons.
Then distros like Fedora could do a one-time migration of their
settings in /etc/sysconfig/foobar and drop the file after the upgrade.
This makes no sense.
Here you are just adding an extra line with no value on top of requiring
some form of standardize the $OPTS var name across daemons ( as opposed
to administrators simply change the value of the line directly ).
Best practice and the least amount of work for administrator ( both in
editing and for other administrators to keep taps on changes made by
others ) is to copy/edit the entire unit.
Lennart can better explain what value he saw in introducing those
snippets compared to that since he introduced them in the first place.
JBG
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
