<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth <span dir="ltr"><<a href="mailto:bpkroth@gmail.com" target="_blank">bpkroth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi again, related to my inetd conversion example, in my .service unit I have something like this:<br>
<br>
# nagios-nrpe-server@.service:<br>
[Service]<br>
Environment=NICENESS=0<br>
EnvironmentFile=-/etc/default/nagios-nrpe-server<br>
ExecStart=/usr/sbin/nrpe -i $DAEMON_OPTIONS<br>
Nice=$NICENESS<br>
<br>
# /etc/default/nagios-nrpe-server:<br>
DAEMON_OPTIONS="--no-ssl"<br>
#NICENESS=5<br>
INETD=1<br>
<br>
<br>
With that I get this sort of error message:<br>
[/etc/systemd/system/nagios-nrpe-server@.service] Failed to parse nice priority, ignoring: $NICENESS<br>
<br>
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.<br>
<br>
<br>
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?<br></blockquote><div><br></div><div>No, they're not expanded anywhere else.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br></blockquote><div><br></div><div>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...</div><div><br></div><div>Though It's slightly different for .service, where a failed ExecStartPre can cancel the start of the main daemon.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Something like:<br>
<br>
# nagios-nrpe-server.socket:<br>
[Unit]<br>
ConditionReturnsZero=/bin/grep -q ^INETD=1$ /etc/default/nagios-nrpe-server<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div>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?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br></blockquote><div><br></div><div>It's expected that people use `systemctl enable` and `systemctl disable` to select between them.</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>