On Fri, Jun 17, 2016 at 6:01 AM, Brian Kroth <bpkr...@gmail.com> 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 <graw...@gmail.com>
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
