Re: [systemd-devel] systemd reboot problem

[Brian Kroth]

In that case, you could also just do something like this:
# for i in {u,s,b}; do echo $i > /proc/sysrq-trigger; done
For "Remount read-only, Sync, (re)Boot".  There are also hotkey sequences
to do that (the modern equivalent of the three fingered salute) which might
be more appropriate in the case of a hanging reboot.  Have a look at the
dmesg output of "echo ? > /proc/sysrq-trigger" or the sysrq-trigger info in
the kernel documentation for other info.

Cheers,
Brian

On Tue, Mar 7, 2017 at 1:31 PM David Strauss  wrote:

> > But I don't want to wait for those services to shutdown.
>
> Then there's no reason to interact with systemd if you want to force an
> immediate, unclean reboot. You just want something like the reboot syscall
> with LINUX_REBOOT_CMD_RESTART.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?

[Brian Kroth]

How about /etc/default/grub.d/ for the kernel parameter drop in file.
That's how I do it at least.

I don't think it's super well documented tho and I forget the suffix it
expects offhand (*.cfg?). Follow the chain of the update-grub scripts and
you should find it.

Cheers,
Brian

On Fri, Jan 20, 2017, 08:53 Patrick Schleizer <
patrick-mailingli...@whonix.org> wrote:

> Hi,
>
> I've learned about the kernel parameter and symlink ways to disable
> predictable network interface names. However, as a Debian derivative, it
> would be much cleaner using a drop-in to disable it.
>
> Is there some drop-in directory foo.service.d that can be used to
> disable it?
>
> Best regards,
> Patrick
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] PAM session hooks for independent session

[Brian Kroth]

On Sat, Oct 29, 2016, 07:02 Reindl Harald  wrote:

>
>
> Am 29.10.2016 um 13:37 schrieb Antoine Martin:
> > Just like "screen" or "tmux", we want to ensure that some xpra sessions
> > (aka "screen for X11", VNC-like but seamless) can survive when the user
> > logs out
>
> which is not longer true
>
> https://www.reddit.com/r/linux/comments/4lebbr/systemd_to_kill_all_user_processes_after_logout/


To be fair though, that was just a change in the default behavior. One can
still disable that functionality in a couple of different ways (system wide
via system.conf, per user "linger" setting, etc.) if they don't like it.

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

Re: [systemd-devel] systemd 210 - mount/umount/remount

[Brian Kroth]

I think there's been some recent discussion related to this on this mailing
list.  You might want to check the archives and/or look into the nofail
and/or noauto options in your fstab entries.  Seems like nofail at least
will change the local-fs.target dependency into a Want instead of a
Require, which may be what you're looking for here.

Cheers,
Brian

On Fri, Oct 14, 2016 at 9:12 AM, Michael Hirmke 
wrote:

> Hi again,
>
> [...]
> >nfsserver and postfix are depending on local-fs.target, which includes
> >var-backup.mount.
> >When stopping /var/backup with systemctl, systemd also stops nfsserver
> >and postfix. Therefore this is not a solution, because in fact both
> >don't need /var/backup.
> >How can I solve this?
>
> it seems to be a very ugly solution, but masking var-backup.mount
> before umounting it and unmasking it after remounting works.
> Hopefully there are no side effects.
>
> Does anyone know any not so ugly solution?
>
> >[...]
>
> Bye.
> Michael.
> --
> Michael Hirmke
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment

[Brian Kroth]

Seems really dependent upon the container layout as to what's the most
appropriate way of doing that. For instance, if the underlying fs of the
source container is something like btrfs or zfs you could imagine doing a
send/recv of a golden snapshot. Possibly also for an lvm volume/snapshot.
For others rsync might be best. For others maybe it's just a deployment
script or tar or git repo.



Cheers,
Brian

On Wed, Oct 12, 2016, 16:23 Samuel Williams 
wrote:

> I'm not sure if this belongs in machinectl, but it would be interesting to
> explore some kind of deployment mechanism. e.g. machinectl deploy
> local-container-name ssh://remote-server:container-name because I'm sure
> this is going to be a really common use case, and there are enough details
> (e.g. stopping and starting the remote machine) that it would be nice to
> keep it easy for new users.
>
> On 13 October 2016 at 02:10, Chris Bell  wrote:
>
> On 2016-10-11 22:29, Samuel Williams wrote:
>
>
> For step 2, what would be the best practice. Rsync the local container
> to the remote container?
>
>
> That's worked fine for me so far. Just to state the obvious: makes sure
> the container is stopped before using rsync.
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] assign variable to some service item

[Brian Kroth]

I asked about something similar to this a while back. I think the answer
was that variable expansion only works in the Exec* directives.

Cheers,
Brian

On Thu, Sep 29, 2016, 03:26 Vasiliy Tolstov  wrote:

> I have CPUAffinity inside service file and want to configure it via
> EnvironmentFile, but
> CPUAffinity=$CPUAffinity does not work with message Failed to parse
> CPU affinity '$CPUAffinity'
> Environment file contains CPUAffinity="0-2"
> Does it possible to assign cpu affinity via env variable ?
> Thanks!
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why do we have aliases fro timedated, resolved, networkd, and what are they good for?

[Brian Kroth]

Umut Tezduyar Lindskog  2016-09-12 07:19:

Hi Michael,

On Sat, Sep 10, 2016 at 1:00 AM, Michael Biebl  wrote:

Hi

I wonder why we have the following aliases/symlinks

dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
dbus-org.freedesktop.import1.service -> systemd-importd.service
dbus-org.freedesktop.locale1.service -> systemd-localed.service
dbus-org.freedesktop.login1.service -> systemd-logind.service
dbus-org.freedesktop.machine1.service -> systemd-machined.service
dbus-org.freedesktop.network1.service -> systemd-networkd.service
dbus-org.freedesktop.resolve1.service -> systemd-resolved.service
dbus-org.freedesktop.timedate1.service -> systemd-timedated.service

Those dbus-org.* aliases are used in the corresponding D-Bus system
service files (SystemdService=dbus-org...)
The symlinks/aliases are created statically in $libdir/systemd/system,
so they can't be removed via systemctl disable.

So, I'm asking myself what good those aliases are for?
They actually have a downside:
We just had a Debian bug report, where a user was masking
systemd-resolved.service, but he was puzzled that he could still
trigger the start of the service via systemd-resolve.
This happened via D-Bus activation and the aliased name (which he had
not masked).


AFAIK, that 2 step service file name is for providing a way to prevent
dbus activation. 


As in, it was intentionally done this way to allow masking a traditional 
service separately from a dbus activate one?


That sorta makes sense that you might want to provide that 
flexibility, but it's somewhat counterintuitive to me in this case.


Since the "service" for both is provided by "systemd-resolved.service" I 
would expect that masking the base name would also prevent activation 
through any aliases.



Maybe my confusion here is in how symlinks are handled generally.

I was under the impression that in most cases it was the names of the 
symlink (source in some contexts, target in others), not the contents of 
it's target that really made a difference.



For instance, I believe I can declare a service as desired for boot, 
even if I don't know where it's actual .service file is (eg: it's 
generated by legacy sysv init script or some such) by simply adding a 
symlink of /etc/systemd/system/multi-user.target.wants.d/foo.service -> 
/bin/true.


The fact that /bin/true isn't itself a unit file doesn't really matter - 
it's more so the presence of a name that matters.  Now, generally 
symlinking to the actual unit is convenient for humans looking at the 
files, though that can still be confusing due to overrides and the like 
and something like "systemctl cat" should probably be used to avoid 
that.



In other contexts, like this one, I was also under the impression that 
the target of the symlink (eg: systemd-resolved.service) was just a 
placeholder that stood for the name of the desired service to provide an 
alias for and that the contents of the file weren't read at that time, 
but rather they were evaluated to the contents of that service or in 
this case appended as an additional name (eg: 
dbus-org.freedesktop.resolve1.service) to that service (eg: 
systemd-resolved.service) once that target service was read in.  Then in 
the case that it was masked, I'd have expected that placeholder-fill-in 
operation to simply not take place.


Does my description make sense?

Granted, I haven't actually read the code for that to confirm that 
impression, but that was my recollection from reading through gobs of 
man pages and the systemd blog posts a few months ago.




Masking resolved alias file should prevent dbus
activation. "systemctl mask dbus-org.freedesktop.resolve1.service".

UMUT


I think the trouble with that is that it requires enumerating all of the 
symlinks and determining what else might link to another service that's 
masked (via a symlink elsewhere) in order to find all of the other 
possible aliases since once you've masked the underlying service, it can 
no longer tell you what it's aliases are via the "systemctl show 
foo.service | grep ^Names=" command for instance:


# systemctl show systemd-resolved.service | grep ^Names=
Names=systemd-resolved.service
# systemctl cat systemd-resolved.service
# /dev/null

So, then one has to do something like this to find the other services 
that might also be aliases:


# for i in $(systemctl list-unit-files --no-legend | awk '{ print $1 }'); do systemctl show $i 
2>/dev/null | grep -q ^Names=.*systemd-resolved && echo "unit-file: '$i' has alias 
of 'systemd-resolved'"; done

That's just not generally something one would probably consider doing 
when attempting to mask a service.


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

Re: [systemd-devel] inetd-style service with connection logging

[Brian Kroth]

Brian Kroth <bpkr...@gmail.com> 2016-06-22 13:48:

On Jun 17, 2016 11:11, "Brian Kroth" <bpkr...@gmail.com> wrote:


Mantas Mikulėnas <graw...@gmail.com> 2016-06-17 08:00:


On Fri, Jun 17, 2016 at 5:05 AM, Brian Kroth <bpkr...@gmail.com> wrote:


Hi, I'm trying to convert an old school inetd service into a systemd
socket activation.

More or less what was describe in [1] worked for me.  However, the bit

I'm

currently missing is connection logging.

With the openbsd-inetd package (Debian), one could enable libwrap style
logging with the -l option to inetd and get something like this:

Jun 16 00:00:16 faitest32 inetd[16032]: connection from 10.130.105.148,
service nrpe (tcp)

Anyone know how to do that with systemd socket/service pairs?  Does it
just require a ExecPreStart sort of rule to echo %i (or some such) into

a

logger pipe (or whatever the journal equivalent of that is), or is

there a

directive to get that that I'm just missing in my googling?



As of v209, the source address is *always* logged when the instance

starts


(well, technically, it's added to the service description) – search the
journal for MESSAGE_ID=39f53479d3a045ac8e11786248231fbf. (Can't filter by
unit unfortunately since UNIT= only has the unique name of the instance,
not the generic one...)

Jun 16 18:19:10 frost systemd[1]: Started OpenSSH Per-Connection Daemon
([fd80:56c2:e21c:288b:8199:931f:3a4e:cfb3]:56168).
Jun 16 18:22:07 frost systemd[1]: Started OpenSSH Per-Connection Daemon (
10.114.14.18:60064).
Jun 17 07:52:34 frost systemd[1]: Started Ident (RFC 1413) per-connection
server ([::1]:50860).



Hmm, I'm running v215 on a Debian Jessie machine, but that MESSAGE_ID

isn't turning anything up for the messages I was expecting.


# journalctl --all -x | grep -i nrpe
...
Jun 17 10:05:15 faitest64 systemd[1]:

[/etc/systemd/system/nagios-nrpe-server@.service:25] Failed to parse nice
priority, ignoring: $NICENESS.


(from before I took that out from my other question thread)


# journalctl MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
-- Logs begin at Thu 2016-06-16 18:46:02 CDT, end at Fri 2016-06-17

11:09:04 CDT. --

Jun 17 00:19:35 faitest64 systemd[886]: Reached target Paths.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Timers.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Sockets.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Basic System.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Default.
Jun 17 00:19:40 faitest64 systemd[886]: Reached target Shutdown.


Do you know the commit id for that change offhand?  Maybe Debian stripped

the patch or something, though I'm not sure why that would have happened.


Thanks,
Brian


Anyone else have any other thoughts on the lack of inetd style connection
logs?

Thanks,
Brian


Ah, I figured it out.  Our grub setup had the "quiet" keyword on the 
boot command line, and the version of systemd (v215) in Debian Jessie 
doesn't include the fix [2] for the issue described in [1].


Basically, there was a hard call to "log_set_max_level(LOG_NOTICE);" in 
the main systemd process while processing the kernel command line 
arguments, which happens after parsing the /etc/systemd/system.conf 
config file, so any LogLevel value set there (mine was explicitly set to 
LogLevel=info) is overwritten.  That wasn't documented so it took a 
while for me to find.


I'll submit a bug to Debian to request a backport of that fix, but in 
the meantime, in case anyone else runs into this, an alternative 
workaround for the meantime is to also include "systemd.log_level=info" 
in the kernel boot parameters (possibly after the "quiet" keyword).


Thanks,
Brian

[1] 
https://lists.freedesktop.org/archives/systemd-devel/2014-December/026271.html 
(commit 5e07a79e)
[2] 
https://lists.freedesktop.org/archives/systemd-devel/2015-February/027946.html 
(commit d7b15e0a)


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

Re: [systemd-devel] inetd-style service with connection logging

[Brian Kroth]

On Jun 17, 2016 11:11, "Brian Kroth" <bpkr...@gmail.com> wrote:
>
> Mantas Mikulėnas <graw...@gmail.com> 2016-06-17 08:00:
>>
>> On Fri, Jun 17, 2016 at 5:05 AM, Brian Kroth <bpkr...@gmail.com> wrote:
>>
>>> Hi, I'm trying to convert an old school inetd service into a systemd
>>> socket activation.
>>>
>>> More or less what was describe in [1] worked for me.  However, the bit
I'm
>>> currently missing is connection logging.
>>>
>>> With the openbsd-inetd package (Debian), one could enable libwrap style
>>> logging with the -l option to inetd and get something like this:
>>>
>>> Jun 16 00:00:16 faitest32 inetd[16032]: connection from 10.130.105.148,
>>> service nrpe (tcp)
>>>
>>> Anyone know how to do that with systemd socket/service pairs?  Does it
>>> just require a ExecPreStart sort of rule to echo %i (or some such) into
a
>>> logger pipe (or whatever the journal equivalent of that is), or is
there a
>>> directive to get that that I'm just missing in my googling?
>>>
>>
>> As of v209, the source address is *always* logged when the instance
starts
>>
>> (well, technically, it's added to the service description) – search the
>> journal for MESSAGE_ID=39f53479d3a045ac8e11786248231fbf. (Can't filter by
>> unit unfortunately since UNIT= only has the unique name of the instance,
>> not the generic one...)
>>
>> Jun 16 18:19:10 frost systemd[1]: Started OpenSSH Per-Connection Daemon
>> ([fd80:56c2:e21c:288b:8199:931f:3a4e:cfb3]:56168).
>> Jun 16 18:22:07 frost systemd[1]: Started OpenSSH Per-Connection Daemon (
>> 10.114.14.18:60064).
>> Jun 17 07:52:34 frost systemd[1]: Started Ident (RFC 1413) per-connection
>> server ([::1]:50860).
>
>
> Hmm, I'm running v215 on a Debian Jessie machine, but that MESSAGE_ID
isn't turning anything up for the messages I was expecting.
>
> # journalctl --all -x | grep -i nrpe
> ...
> Jun 17 10:05:15 faitest64 systemd[1]:
[/etc/systemd/system/nagios-nrpe-server@.service:25] Failed to parse nice
priority, ignoring: $NICENESS.
>
> (from before I took that out from my other question thread)
>
>
> # journalctl MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
> -- Logs begin at Thu 2016-06-16 18:46:02 CDT, end at Fri 2016-06-17
11:09:04 CDT. --
> Jun 17 00:19:35 faitest64 systemd[886]: Reached target Paths.
> Jun 17 00:19:35 faitest64 systemd[886]: Reached target Timers.
> Jun 17 00:19:35 faitest64 systemd[886]: Reached target Sockets.
> Jun 17 00:19:35 faitest64 systemd[886]: Reached target Basic System.
> Jun 17 00:19:35 faitest64 systemd[886]: Reached target Default.
> Jun 17 00:19:40 faitest64 systemd[886]: Reached target Shutdown.
>
>
> Do you know the commit id for that change offhand?  Maybe Debian stripped
the patch or something, though I'm not sure why that would have happened.
>
> Thanks,
> Brian

Anyone else have any other thoughts on the lack of inetd style connection
logs?

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

Re: [systemd-devel] inetd-style service with connection logging

[Brian Kroth]

Mantas Mikulėnas <graw...@gmail.com> 2016-06-17 08:00:

On Fri, Jun 17, 2016 at 5:05 AM, Brian Kroth <bpkr...@gmail.com> wrote:


Hi, I'm trying to convert an old school inetd service into a systemd
socket activation.

More or less what was describe in [1] worked for me.  However, the bit I'm
currently missing is connection logging.

With the openbsd-inetd package (Debian), one could enable libwrap style
logging with the -l option to inetd and get something like this:

Jun 16 00:00:16 faitest32 inetd[16032]: connection from 10.130.105.148,
service nrpe (tcp)

Anyone know how to do that with systemd socket/service pairs?  Does it
just require a ExecPreStart sort of rule to echo %i (or some such) into a
logger pipe (or whatever the journal equivalent of that is), or is there a
directive to get that that I'm just missing in my googling?



As of v209, the source address is *always* logged when the instance starts
(well, technically, it's added to the service description) – search the
journal for MESSAGE_ID=39f53479d3a045ac8e11786248231fbf. (Can't filter by
unit unfortunately since UNIT= only has the unique name of the instance,
not the generic one...)

Jun 16 18:19:10 frost systemd[1]: Started OpenSSH Per-Connection Daemon
([fd80:56c2:e21c:288b:8199:931f:3a4e:cfb3]:56168).
Jun 16 18:22:07 frost systemd[1]: Started OpenSSH Per-Connection Daemon (
10.114.14.18:60064).
Jun 17 07:52:34 frost systemd[1]: Started Ident (RFC 1413) per-connection
server ([::1]:50860).


Hmm, I'm running v215 on a Debian Jessie machine, but that MESSAGE_ID 
isn't turning anything up for the messages I was expecting.


# journalctl --all -x | grep -i nrpe
...
Jun 17 10:05:15 faitest64 systemd[1]: 
[/etc/systemd/system/nagios-nrpe-server@.service:25] Failed to parse nice 
priority, ignoring: $NICENESS.

(from before I took that out from my other question thread)


# journalctl MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
-- Logs begin at Thu 2016-06-16 18:46:02 CDT, end at Fri 2016-06-17 11:09:04 
CDT. --
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Paths.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Timers.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Sockets.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Basic System.
Jun 17 00:19:35 faitest64 systemd[886]: Reached target Default.
Jun 17 00:19:40 faitest64 systemd[886]: Reached target Shutdown.


Do you know the commit id for that change offhand?  Maybe Debian 
stripped the patch or something, though I'm not sure why that would have 
happened.


Thanks,
Brian


signature.asc
Description: Digital signature
___
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 <graw...@gmail.com> 2016-06-17 07:47:

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?


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] 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

[systemd-devel] inetd-style service with connection logging

[Brian Kroth]

Hi, I'm trying to convert an old school inetd service into a systemd 
socket activation.


More or less what was describe in [1] worked for me.  However, the bit 
I'm currently missing is connection logging.


With the openbsd-inetd package (Debian), one could enable libwrap style 
logging with the -l option to inetd and get something like this:


Jun 16 00:00:16 faitest32 inetd[16032]: connection from 10.130.105.148, service 
nrpe (tcp)

Anyone know how to do that with systemd socket/service pairs?  Does it 
just require a ExecPreStart sort of rule to echo %i (or some such) into 
a logger pipe (or whatever the journal equivalent of that is), or is 
there a directive to get that that I'm just missing in my googling?


Thanks,
Brian

[1] 


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

Re: [systemd-devel] network unit Match by router advertisement?

[Brian Kroth]

Lennart Poettering <lenn...@poettering.net> 2016-05-11 19:31:

On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote:


Hi again all,

TL;DR: would it be possible (or make sense) to have systemd Match rules for
network units that could match on some artifact of the network the link is
attached to like vlan tag, router advertisement, wireless access point or
gateway mac, etc.?


Well, .network files contain the definition how to set up a network
interface, i.e. how to place it into UP state so that packets can be
received and how to configure IP routing so that communication further
on works. Hence: it uses relatively static properties of the device
that are already available when the device is offline, to find the
right .network file to read the dynamic configuration to apply in
order to put it online. The router advertisment info and things like
the gateway mac are pieces of information that are only available when
the network is already up, when the network configuration is already
applied. Hence using that as match for the configuration can't work:
at the time we could use that information we already would have had to
apply it. And if we don't apply it, we would never get the information
to acquire...


True.  So maybe I needed to use a .link or .netdev unit in this example 
case instead of a .network.



The VLAN tag is a different case though: it's assigned when the
VLAN networkd device is created, and configured in the .netdev
configuration file for that. Thus, it's already set the moment the
network device pops up, and it could be used nicely for the
matching. So yupp, added a MatchVLANId= or so, might make
sense. Please file an RFE issue on github about this, if you'd like to
see this implemented.

Matching by AP could work. Iirc today's WLAN drivers actually will
create virtual links for the network you connect to, and the ESSID for
each would be set before networkd would take notice of it, hence this
is probably something we could do. Note however, that networkd does
not interface with the WLAN stack at all at this point, a WLAN device
is treated like any other Ethernet device atm.


I hadn't actually looked at the WLAN side of it too much.  For the past 
many years NetworkManager on my laptop has Just Worked and so I haven't 
had to worry or think about it as much.  I just sort of threw that out 
there as another example use case and in the spirit of "can I reduce my 
package dependencies a tad if systemd is already capable of handling 
some of that for me".



However, the missing bit then would be network address assignment for the
various instances to the right interfaces.  Ideally, I'd just stamp out
network unit files and have the apache instance units depend upon that, but
the trouble is that traditionally NIC naming hasn't always been consistent
in the past.

I've read through [1], but it doesn't really provide what I'm looking for.
Physical layout of the nic-port-types is semi interesting and perhaps
consistent, but network operator error may result in a misassigned vlan
port, or simply the wrong cable to the wrong port (which can be true for
physical or virtual realms unfortunately), etc.

What I did in the past to work around that was to use ndisc6 or something
similar to verify that the expected interface had the expected network
properties - in this case a router advertisement.


Hmm, schemes like this sound a bit dangerous, no? I mean, if you base
your decision whether to apply the relatively open "internal LAN"
config to an interface or the restricted "internet" config on the
traffic you see on the port, then you make yourself vulnerable to
people sending you rogue IP packets...


Could be.  In our particular environment RAs are blocked off to certain 
trusted switch ports much like DHCPOFFERs are generally, so I'm not as 
worried about it, but it'd certainly be something people need to be 
aware of.


I guess the bigger idea behind the theory was to make the network 
configuration determinations based upon what we actually observe or 
expect the external/physical config to look like, which seemed like a 
generally powerful and useful technique.



I see your usecase though, but I don't really have any good suggestion
what to do in this case I must say...


That's fine.  I'll just stick with some external scripts for the moment.  
Or maybe try and cook up some Condition*= dependency magic similar to what 
was being discussed in the dhcpd lint checking thread recently.



Maybe adding something like a RequireDHCPServer= setting or so, that
allows configuration of a DHCP server address, and when set would
result in logged warnings if DHCP leases are offered from other
servers thatn the configured one, might be an option? i.e. so that you
at least get a loggable event when some .network file is applied to
the wrong iface?

But dunno, maybe Tom has an idea about this? Tom?


[2] Sidenote: In the past I've used an old trick of setting the
p

Re: [systemd-devel] default service restart action?

[Brian Kroth]

On May 11, 2016 12:07, "Lennart Poettering" <lenn...@poettering.net> wrote:
>
> On Wed, 11.05.16 11:27, Brian Kroth (bpkr...@gmail.com) wrote:
>
> > Hi all, I'm in the midst of steeping myself in systemd docs as I
prepare to
> > face lift a slew of services for Debian Jessie updates.
> >
> > As I read through things I'm starting to think through a number of new
ways
> > I could potentially reorganize some of our services, which is cool.
With my
> > ideas though I think I'm finding a few gaps in either my understanding
or
> > systemd capabilities, so I wanted to send a few questions to the list.
> > Hopefully this is the right place.
> >
> > The first should hopefully be a bit of a softball:
> >
> > With .service units one can specify OnFailure and other sorts of restart
> > behaviors, including thresholds and backoffs for when to stop retrying
and
> > what to do then. Essentially a lightweight service problem escalation
> > procedure.
> >
> > However, in reading systemd-system.conf, I don't see any way to specify
> > something like DefaultOnFailure behavior for what to do on failure,
perhaps
> > after some simple restart attempts, for all services.  Seems like it can
> > only be done on a per unit basis, no?
>
> That is correct, yes.
>
> > Ideally, I'd like to be able to do something very simply like, declare
> > if any service fails to restart itself or does so too often and enters a
> > hard failure state, then systemd should (attempt to) fire off an
> > escalation procedure unit like send a passive check status to Nagios or
> > send an email, accepting that such procedures may depend upon network
> > connectivity which may or may not be available (so maybe there's some
> > circular dependency issues to work through in such a scenario, but I
> > presume systemd already has facilities for handling that case, maybe via
> > OnFailureJobMode= settings).
> >
> > Thoughts?
>
> That sounds like it goes towards service monitoring?
>
> I figure our theory there was that monitoring systems should probably
> keep an eye on the journal stream generated, where there are events
> generated about these issues. These log entries are recognizable by
> their message ID and carry both human readable as well as structured
> metadta that let you know what's going on. Our plan was originally to
> then add a concept of "activation-by-log-event" to systemd, so that
> you could activate some service each time a log event of a certain
> kind happens. However, we never came around to actually hack that up,
> it's still on the TODO list.
>
> I think OnFailure= and stuff are pretty useful for some things, but
> for the monitoring case such a journal-based logic would be nicer,
> because it can cover events triggered in a quick pace and during early
> boot nicer, as they processing of this can happen serially and
> asynchronously... Also, it would allow much nicer filtering for any
> kind of event on the system, and we wouldn't happen to hook up every
> kind of failure of each service with a OnFailure= like dependency.
>
> So yeah, I think we should have better support for what you are trying
> to do, but I think we should best do that by delivering the
> activate-by-log-message feature after all...
>
> Lennart

Thanks, I'll look into that technique.

Essentially in this case it'd be another .service script monitoring journal
activity, perhaps with some filters, or else just a periodic cron job.
Either way, I think you're right - that's probably the more generally
applicable approach.

I must admit I'd only done enough research/understanding of journald to get
my syslog stuff working again. I hadn't really thought through what else it
might offer/enable.  Now that I have, I'm starting to see nice aspects to
it.  Too bad Debian Jessie is a little bit behind on a number of its
(coredumpctl) and support cast (syslog-ng) features.

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

Re: [systemd-devel] Performing a config check before restarting a process

[Brian Kroth]

Terry Burton  2016-05-16 17:43:

On 13 May 2016 at 00:04, Terry Burton  wrote:

I have a process (ISC DHCP) that has no reload or soft restart
mechanism. The only way to "reload" it is a stop and start.

I understand systemd's design choice of maintaining a clear
distinction between reload and restart based on whether the service is
interrupted or not, so it's clear that I should use restart.

However, in the event that the user invokes "restart" I would like to
validate the config file before taking the Stop action to avoid loss
of service (as was the case for the reload action of my previous init
scripts.)

We do not however have ExecStopPre and there does not appear to be a
way to interrupt a Stop action based on the result of ExecStop so I'm
not sure where that leaves me? Does anyone have a useful recipe that
accomplishes this?

Perhaps such a config check is considered one of those things that
lives in a support script or user's best practises outside of the init
system... That seems a shame though.


A quick nudge before moving along...


Still learning the ins and outs of systemd myself, so I don't think I 
have a solution for you, but I'd also be interested in this.  I've run 
into a few cases where I expected something to reload/restart and didn't 
realize that it hadn't because the output was buried in the journal 
somehow.



In the past I might have done something like this in an 
/etc/default/dhcpd file (in Debian based distros) knowing that it would 
be sourced as a generic shell file by the init script before actually 
being run and not just a list of key=value environment variable pairs 
like systemd expects:


CONFFILE='/etc/dhcp/dhcpd.conf'
if [ "$1" != "stop" ]; then
if ! dhcpd -t -cf "$CONFFILE" > /dev/null; then
echo "ERROR: '$CONFFILE' failed to lint check.  Check the logs for 
details." >&2
exit 1
fi
fi
# else, let it pass


I was hoping there was something like a 
ConditionReturnsZero=/path/to/some/script that would prevent 
start/stop/restart/etc. actions if the script didn't exit 0.


Maybe you could hack around that with something like the following 
(totally untested):


/etc/systemd/system/dhcpd-lint-check.service:

[Unit]
Before=dhcpd.service

[Service]
Type=oneshot
ExecStartPre=/bin/rm -f /etc/dhcp/dhcpd-conf-lint-checks-ok
ExecStart=/usr/sbin/dhcpd -t -cf /etc/dhcp/dhcpd.conf
ExecStartPost=/usr/bin/touch /etc/dhcp/dhcpd-conf-lint-checks-ok
RemainAfterExit=false

[Install]
WantedBy=dhcpd.service


/etc/systemd/system/dhcpd.service.d/01-lint-check-condition.conf:

[Unit]
ConditionPathExists=/etc/dhcpd/dhcpd-conf-lint-checks-ok


Basically, add a condition to the dhcpd service for a canary file 
existing.  That canary file gets managed by a mini oneshot service that 
checks the dhcpd.conf file for sanity, but doesn't remain, so I think 
that it should be attempted to be started before the dhcpd.service is.  
Probably I'm missing some ordering/dependency races though.  Maybe the 
ExecStartPost needs to be combined with ExecStart in a shell && style 
combo.  Not sure offhand.


Anyways, let us know if you do find something that works out for you.

Thanks,
Brian


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

[systemd-devel] network unit Match by router advertisement?

[Brian Kroth]

Hi again all,

TL;DR: would it be possible (or make sense) to have systemd Match rules for
network units that could match on some artifact of the network the link is
attached to like vlan tag, router advertisement, wireless access point or
gateway mac, etc.?

So, the original motivation for this question comes from a web hosting
platform we developed that uses something like lightweight pre-containers
for running multiple apache instances per VM.  Multiple instances per VM,
each running as their own user, in order to avoid the overhead of full on
VMs for each apache (which are generally mostly idle) without the
performance overhead of something like suexec.  In order to run them each
as their own user, we bound them each to their own IPv6 address [2].  A
separate reverse proxy setup provides IPv4 connectivity, caching, security
filters, etc.

Anyways, in the past all of this dependency and setup madness was managed
with some Perl scripts and a database that would just setup appropriate
conf files on disk, addresses on the appropriate network interfaces (there
are between two or four on each node), and environment variables before
calling the standard sysv init script multiple times to start each instance.

As I'm thinking about how I could move towards a systemd integrated system,
I'm hoping to summarize this process to just stamping out (possibly
instanced) apache service unit files, php-fpm unit files, maybe some slice
unit files for arranging them into appropriate cgroup hierarchies, maybe
some lightweight container features like fs namespaces, probably grouped by
some target(s) for handling batch operations, etc., and just make systemd
manage the process dependencies starting/stopping/monitoring/etc.

However, the missing bit then would be network address assignment for the
various instances to the right interfaces.  Ideally, I'd just stamp out
network unit files and have the apache instance units depend upon that, but
the trouble is that traditionally NIC naming hasn't always been consistent
in the past.

I've read through [1], but it doesn't really provide what I'm looking for.
Physical layout of the nic-port-types is semi interesting and perhaps
consistent, but network operator error may result in a misassigned vlan
port, or simply the wrong cable to the wrong port (which can be true for
physical or virtual realms unfortunately), etc.

What I did in the past to work around that was to use ndisc6 or something
similar to verify that the expected interface had the expected network
properties - in this case a router advertisement.

Something similar in a Match section in systemd network units I would think
could be useful.  It could also be extended to other ideas like which
wireless access point you're attached to at the moment, or what the MAC
address of the gateway is that DHCP assigned to you, or what tagged vlan
attributes you see on the wire, etc. That could be used to fire off other
configuration events, especially in the case of mobile clients, when
systemd discovers via network artifacts that the machine has moved to a new
location and the user may want to perform some extra config actions, a
backup job, etc.

The only other way I can think of to emulate this might be to write a
series of udev rules that executed the appropriate discovery and matching
commands and then assigned interface alias names and then match on that in
the network units.  For instance, through RAs or VLAN tags I might
determine that the interface is on VLAN 123, so I create an interface alias
of vlan123, and then use network unit rules to match on that name when the
link is up and an appropriate service registers a need for the address.

I haven't dug through udev enough to try that yet, but it seems too
procedural to me for such a general sort of desire.  I like the
semi-declaritive style of configuration that systemd generally enables.

I guess the other option would be to just make them standalone Exec...
statement units like I did before, but again that seems too proceedural to
me.

Make sense?  Thoughts?

Thanks,
Brian

[1] <
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>

[2] Sidenote: In the past I've used an old trick of setting the
preferred_lft to 0 for IPv6 addresses that I wanted to be available to
services, but not selected for outbound connections from the host.  This
was basically to help influence the usual source address selection criteria
which tries to avoid "deprecated" addresses.  I didn't see a way to specify
that in the systemd.network man page.  Is there one that I'm missing, or is
that another case for an Exec... statement?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] default service restart action?

[Brian Kroth]

Hi all, I'm in the midst of steeping myself in systemd docs as I prepare to
face lift a slew of services for Debian Jessie updates.

As I read through things I'm starting to think through a number of new ways
I could potentially reorganize some of our services, which is cool. With my
ideas though I think I'm finding a few gaps in either my understanding or
systemd capabilities, so I wanted to send a few questions to the list.
Hopefully this is the right place.

The first should hopefully be a bit of a softball:

With .service units one can specify OnFailure and other sorts of restart
behaviors, including thresholds and backoffs for when to stop retrying and
what to do then. Essentially a lightweight service problem escalation
procedure.

However, in reading systemd-system.conf, I don't see any way to specify
something like DefaultOnFailure behavior for what to do on failure, perhaps
after some simple restart attempts, for all services.  Seems like it can
only be done on a per unit basis, no?

Ideally, I'd like to be able to do something very simply like, declare
if any service fails to restart itself or does so too often and enters a
hard failure state, then systemd should (attempt to) fire off an
escalation procedure unit like send a passive check status to Nagios or
send an email, accepting that such procedures may depend upon network
connectivity which may or may not be available (so maybe there's some
circular dependency issues to work through in such a scenario, but I
presume systemd already has facilities for handling that case, maybe via
OnFailureJobMode= settings).

Thoughts?

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