[systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
Lennart Poettering
lennart at poettering.net
Wed Apr 17 17:40:15 PDT 2013
On Wed, 10.04.13 16:53, harald at redhat.com (harald at redhat.com) wrote:
> From: Harald Hoyer <harald at redhat.com>
>
> This patch adds environment variable substition for PIDFile=. To read
> the environment files only once, ExecContext holds a copy of the
> environment gathered.
>
> RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260
I am really not convinced about this one. The final environment is only
put together right before we execute a binary, and resolving this much
earlier sounds like the wrong thing to do, because it would necessarily
not be in sync with the environment we pass to the binary.
Also, we currently do not resolve environment variables in any directive
except ExecXYZ=. If we begin doing this here, then people want it
everywhere, and things become really messy...
This makes it particularly hard for people to write sane external parsers
for this, since suddenly to understand unit files you actually need to
resolve env vars, it is no longer sufficient to resolve env vars only
when executing things, i.e. to leave that to systemd...
Then, the whole PID file story looks like a mess to me anyway, modern
daemons should not use PID files anyway... Even more, making them
configurable sounds really wrong. If this is about allowing
instantiation, then people can use %i in the PID file name, and be done
with it, but otherwise this sounds like a completely ridiculous
configuration option in sysconfig, like the first one to get rid
of... So the usecase already sounds really wrong to me, to start with.
This really sounds like a bug to me we should close WONTFIX with a nice
explanation. I know Tom won't like that, but well, sometimes we have to
say No to wishes.
I know I though different about this in January (and commented so in the
bug), but in retrospect I must disagree with myself on this...
Sorry,
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list