Re: [systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
Am 18.04.2013 02:40, schrieb Lennart Poettering: On Wed, 10.04.13 16:53, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@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 fair enough, care to close the bug then? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
On Thu, 18.04.13 08:46, Harald Hoyer (har...@redhat.com) wrote: 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... fair enough, care to close the bug then? OK, done! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=
On Wed, 10.04.13 16:53, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
