Re: [systemd-devel] environment variable questions

[Mantas Mikulėnas]

On Fri, Jun 17, 2016 at 7:04 PM, Brian Kroth  wrote:

> Mantas Mikulėnas  2016-06-17 07:47:
>
> On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth  wrote:
>>
>> Hi again, related to my inetd conversion example, in my .service unit I
>>> have something like this:
>>>
>>> # nagios-nrpe-server@.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@.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 ` (when a more recent systemd reaches your
distro), and `systemd-delta`.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] environment variable questions

[Brian Kroth]

Mantas Mikulėnas  2016-06-17 07:47:

On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth  wrote:


Hi again, related to my inetd conversion example, in my .service unit I
have something like this:

# nagios-nrpe-server@.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@.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.



Also, so long as I'm asking questions, I've got one about Condition*
directives.  There doesn't seem to be one for Environment variable sort of
parsing or some sort of shell command evaluation (eg: returns 0 kinda
thing).



Nope. (I think this was rejected once already.) Ask #debian-systemd about
how they're dealing with the existing /etc/default files with "ENABLE=yes"
during upgrades to native units...


Will do, thanks.


Though It's slightly different for .service, where a failed ExecStartPre
can cancel the start of the main daemon.

There's also the "generator" concept, where external tools are used to
create actual unit files in RAM (or do the equivalent of `systemctl
enable`) before systemd even starts the boot process; this is how
/etc/fstab is parsed into .mount units by fstab-generator, for example, and
also how Debian's sysv-generator creates fake .service units for old
/etc/init.d scripts.


Yeah, I get the reason for those, but I find them somewhat opaque when 
trying to analyze the configuration of a system, especially outside of a 
running system itself (eg: just on the config management end of things).



Something like:


# nagios-nrpe-server.socket:
[Unit]
ConditionReturnsZero=/bin/grep -q ^INETD=1$ /etc/default/nagios-nrpe-server

I got to thinking about this for the INETD directive that comes in the
/etc/default/nagios-nrpe-server script.  It's somewhat irrelevant in this
case since the .socket unit already needs to be active before the @.service
pair is instantiated.

Looking at some of the other examples the system ships with like
ssh.service vs ssh@.service/ssh.socket, they have Conflicts= directives
against each other, but there's not really a conf file that I see that
directs the system to use inetd-style vs daemon mode for those.



I'm not really sure how this could have worked even before systemd.. I
mean, this would be selecting between two entirely separate systems, and
even if the init.d scripts understood that INETD=yes means "do not start
the daemon", I doubt [x]inetd itself cared about configuration /etc/default
at all. (Did it?)


No, that's a good point.  I think you're probably right: there are inetd 
helpers for dpkg at least, but I think it was probably still up to the 
admin to make sure one was disabled and the other was enabled, so that 
notion at least doesn't change - just the mechanism.



So, since there's not really a way to read that from an EnvironmentFile
style conf file and use it in a Conditional* directive to disable one vs
the other right now, is it just expected that people use something like
"systemctl mask ssh.service" vs. "systemctl mask ssh.socket" to select
between them?



It's expected that people use `systemctl enable` and `systemctl disable` to
select between them.


K, that's what I figured.  Good to hear it from another source though.

Thanks again.

Cheers,
Brian


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

Re: [systemd-devel] environment variable questions

[Mantas Mikulėnas]

On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth  wrote:

> Hi again, related to my inetd conversion example, in my .service unit I
> have something like this:
>
> # nagios-nrpe-server@.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@.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?


> Also, so long as I'm asking questions, I've got one about Condition*
> directives.  There doesn't seem to be one for Environment variable sort of
> parsing or some sort of shell command evaluation (eg: returns 0 kinda
> thing).
>

Nope. (I think this was rejected once already.) Ask #debian-systemd about
how they're dealing with the existing /etc/default files with "ENABLE=yes"
during upgrades to native units...

Though It's slightly different for .service, where a failed ExecStartPre
can cancel the start of the main daemon.

There's also the "generator" concept, where external tools are used to
create actual unit files in RAM (or do the equivalent of `systemctl
enable`) before systemd even starts the boot process; this is how
/etc/fstab is parsed into .mount units by fstab-generator, for example, and
also how Debian's sysv-generator creates fake .service units for old
/etc/init.d scripts.

Something like:
>
> # nagios-nrpe-server.socket:
> [Unit]
> ConditionReturnsZero=/bin/grep -q ^INETD=1$ /etc/default/nagios-nrpe-server
>
> I got to thinking about this for the INETD directive that comes in the
> /etc/default/nagios-nrpe-server script.  It's somewhat irrelevant in this
> case since the .socket unit already needs to be active before the @.service
> pair is instantiated.
>
> Looking at some of the other examples the system ships with like
> ssh.service vs ssh@.service/ssh.socket, they have Conflicts= directives
> against each other, but there's not really a conf file that I see that
> directs the system to use inetd-style vs daemon mode for those.
>

I'm not really sure how this could have worked even before systemd.. I
mean, this would be selecting between two entirely separate systems, and
even if the init.d scripts understood that INETD=yes means "do not start
the daemon", I doubt [x]inetd itself cared about configuration /etc/default
at all. (Did it?)


> So, since there's not really a way to read that from an EnvironmentFile
> style conf file and use it in a Conditional* directive to disable one vs
> the other right now, is it just expected that people use something like
> "systemctl mask ssh.service" vs. "systemctl mask ssh.socket" to select
> between them?
>

It's expected that people use `systemctl enable` and `systemctl disable` to
select between them.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] environment variable questions

[Andrei Borzenkov]

17.06.2016 06:01, Brian Kroth пишет:
> 
> 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?
> 

Yes. Environment substitutions are only interpreted in Exec* directives.

> 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] environment variable questions

[Brian Kroth]

Hi again, related to my inetd conversion example, in my .service unit I 
have something like this:


# nagios-nrpe-server@.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@.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?



Also, so long as I'm asking questions, I've got one about Condition* 
directives.  There doesn't seem to be one for Environment variable sort 
of parsing or some sort of shell command evaluation (eg: returns 0 kinda 
thing).


Something like:

# nagios-nrpe-server.socket:
[Unit]
ConditionReturnsZero=/bin/grep -q ^INETD=1$ /etc/default/nagios-nrpe-server

I got to thinking about this for the INETD directive that comes in the 
/etc/default/nagios-nrpe-server script.  It's somewhat irrelevant in 
this case since the .socket unit already needs to be active before the 
@.service pair is instantiated.


Looking at some of the other examples the system ships with like 
ssh.service vs ssh@.service/ssh.socket, they have Conflicts= directives 
against each other, but there's not really a conf file that I see that 
directs the system to use inetd-style vs daemon mode for those.


So, since there's not really a way to read that from an EnvironmentFile 
style conf file and use it in a Conditional* directive to disable one vs 
the other right now, is it just expected that people use something like 
"systemctl mask ssh.service" vs. "systemctl mask ssh.socket" to select 
between them?


Thanks,
Brian


signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel