[systemd-devel] environment variable questions

[Mantas Mikulėnas]

On Fri, Jun 17, 2016 at 7:04 PM, Brian Kroth <bpkroth at gmail.com> wrote:

> Mantas Mikulėnas <grawity at gmail.com> 2016-06-17 07:47:
>
> On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth <bpkroth at gmail.com> wrote:
>>
>> Hi again, related to my inetd conversion example, in my .service unit I
>>> have something like this:
>>>
>>> # nagios-nrpe-server at .service:
>>> [Service]
>>> Environment=NICENESS=0
>>> EnvironmentFile=-/etc/default/nagios-nrpe-server
>>> ExecStart=/usr/sbin/nrpe -i $DAEMON_OPTIONS
>>> Nice=$NICENESS
>>>
>>> # /etc/default/nagios-nrpe-server:
>>> DAEMON_OPTIONS="--no-ssl"
>>> #NICENESS=5
>>> INETD=1
>>>
>>>
>>> With that I get this sort of error message:
>>> [/etc/systemd/system/nagios-nrpe-server at .service] Failed to parse nice
>>> priority, ignoring: $NICENESS
>>>
>>> I added the leading "Environment=NICENESS=0" directive to try and make
>>> sure it wasn't just an empty variable kinda thing, but it didn't seem to
>>> help.
>>>
>>>
>>> It's somewhat unclear from the man pages as to whether or not $VAR
>>> expansion is done outside of the Exec* directives, and I couldn't find a
>>> definitive answer online, but based on the above, I'm guessing it's not,
>>> correct?
>>>
>>>
>> No, they're not expanded anywhere else.
>>
>> Generally it's best to entirely avoid indirection via /etc/default, and
>> just configure daemons directly via their .service units. (Unlike init
>> scripts, they're freely editable by sysadmins.) In certain cases, a
>> variable for command-line arguments might make sense, but $NICENESS? Why?
>>
>
> It was mostly an exercise in understanding as I went through the process
> of trying to convert a legacy init script over for myself.
>
> I think I agree with you that it's easy enough to add the
> /etc/systemd/system/$service.conf.d/override.conf style overrides for
> individual parameters like that.
>
> The distaste I guess I'm left with is that, at least as things transition,
> we end up having to look in several places to figure out where all the
> configuration sources are coming from (eg: /etc/default,
> /{etc,run,lib}/systemd, etc.).  It's not always clear on first glance which
> parts are respected by other parts.


Use `systemctl cat <service>` (when a more recent systemd reaches your
distro), and `systemd-delta`.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160617/3a61f470/attachment.html>