Re: [systemd-devel] keeping a backup ESP partition in sync

[Kevin P. Fleming]

> (the way I'd implement this, is not by actually teaching these
> commands individual multi-ESP support, but simply by implementing a
> single sync_esp() call or so which syncs the relavant info from
> primary to secondary ESPs correctly, and that each of these commands
> just call as last step. For single-ESP setups this call would be a NOP)

Just a reminder (Lennart mentioned it above, but it's worth repeating): for 
this purpose, 'primary' means the one that the system was booted from.

Re: [systemd-devel] keeping a backup ESP partition in sync

[Kevin P. Fleming]

On Fri, May 17, 2024, at 05:03, Alexander Gordeev wrote:
> I think it is better to have them mounted as e.g. /boot/efi and
> /boot/eficopy and make changes like this:
> 1. update /boot/efi
> 2. make sure the update is actually written to the device
> 3. update /boot/eficopy
>
> Right now I do this manually with rsync. I'm thinking about adding
> kernel/initramfs/dpkg hooks. Maybe there are easier ways to do it?
> Otherwise maybe this feature is desirable in systemd-boot?

https://github.com/gregory-lee-bartholomew/bootsync

This is what I use, it works very well.

Re: [systemd-devel] Custom systemctl service issue

[Kevin P. Fleming]

On Sun, Mar 10, 2024, at 16:14, Ricardo wrote:
> On a custom systemctl service, when start service it seems starting without 
> any message, but when it check by journalctl command it reporter as Failure.
> 
> But if manually run service program it starts without any problem and message.
> 
> The bellow is program to execute as service, which have work without any 
> problems on previous linux service.
> 
> # asterisk
> 
> # asterisk -rx "core stop now"
> 
> 
> 
> 
> # systemctl start asterisk.service
> 

This only issues a request to start the service; it does not actually wait for 
the service to start, or report on the results of the start request.

> #
> 
> # journalctl -xe |grep asterisk
> 
> -- Subject: Unit asterisk.service has finished start-up
> 
> -- Unit asterisk.service has finished starting up.
> 
> Mar 10 10:20:15 localhost.localdomain asterisk[1536]: ASTdb initialization 
> failed. ASTERISK EXITING!
> 
> Mar 10 10:20:15 localhost.localdomain asterisk[1536]: Unable to open Asterisk 
> database '/var/lib/asterisk/astdb.sqlite3': unable to open database file
> 
> Mar 10 10:20:15 localhost.localdomain systemd[1]: asterisk.service: main 
> process exited, code=exited, status=1/FAILURE
> 
> Mar 10 10:20:15 localhost.localdomain systemd[1]: Unit asterisk.service 
> entered failed state.
> 
> Mar 10 10:20:15 localhost.localdomain systemd[1]: asterisk.service failed.
> 

The program was unable to access it database, likely due to the configuration 
in the .service file. It may be running as the wrong user/group, or have 
filesystem protection settings which disallow access to /var/lib/asterisk, or 
possibly other things. Running the program manually would not have the same 
restrictions in place, even if it is run as the proper user and group.

Check the asterisk.service file, in particular the [Service] section, to see if 
there are any sandboxing restrictions being placed on the service.

Re: [systemd-devel] How can I prevent systemd.network from auto-deleting my manually-assigned static IPv4 addresses?

[Kevin P. Fleming]

I believe you want KeepConfiguration="static".

On Wed, Sep 13, 2023, at 18:32, Jeremy Friesner wrote:
> Hi all,
> 
> I apologize for this basic question, but I haven’t been able to figure it out 
> on my own.
> 
> I’m working on an embedded device, which includes a little GUI that (among 
> other things) allows the user to specify a static IPv4 address (and netmask 
> and gateway) to be associated with a given Ethernet port on the device.
> 
> The user enters the IPv4 settings-values he wants into the GUI, clicks 
> “Apply”, and the server runs a couple of simple shell commands:
> 
> /sbin/ip -4 a add 192.168.2.88/24 dev eno1 label eno1:p0s0
> /bin/arping -c 3 -A -I eno1 192.168.2.88
> 
> … et voila, Ethernet device eno1 now uses the IP address 192.168.2.88 
> (associated with the label eno1:p0s0), as shown in ifconfig:
> 
> root@embedded-device:~# ifconfig
> […]
> 
> eno1:p0s0 Link encap:Ethernet HWaddr 00:07:32:95:93:7D 
> inet addr:192.168.2.88 Bcast:0.0.0.0 Mask:255.255.255.0
> UP BROADCAST MULTICAST MTU:1500 Metric:1
> Memory:a5b0-a5b1
> 
> If the user later changes his mind and wants to clear his IPv4 settings, he 
> can do that and the server will run this shell command:
> 
> /sbin/ip -4 addr flush label eno1:p0s0
> 
> This all works fine and has for a long time; the problem is that the new 
> version of the device is running systemd.networkd and networkd has some 
> functionality in it where it detects when an Ethernet device has lost its 
> carrier, and responds by removing all the IPv4 addresses associated with that 
> Ethernet device.
> 
> The user-visible result of that behavior is that if the user unplugs his 
> Ethernet cable and then plugs it in again, his IPv4 settings are no longer in 
> effect (at least not until he goes and re-enters them into the GUI again to 
> re-establish them).
> 
> The behavior I would like is that this manually-assigned IPv4 address is left 
> alone by systemd, and doesn’t change unless/until the user explicitly updates 
> it using the GUI.  Is there some way to convince networkd to leave my 
> server’s IPv4 settings alone?
> 
> I tried various permutations of config files, like the one shown below, but 
> they didn’t seem to have any effect on networkd's behavior.
> 
> root@embedded-device:~# cat /etc/systemd/network/eno1.network 
> [Match]
> Name=eno1
> 
> [Network]
> DHCP=no
> IgnoreCarrierLoss=yes
> 
> [Link]
> ActivationPolicy=always-up
> 
> Thanks,
> Jeremy
> NOTICE: This email may contain confidential information. Please see 
> https://meyersound.com/legal/#email-policy for our complete policy.

Re: [systemd-devel] multiple starts for a socket-based service

[Kevin P. Fleming]

On Fri, Aug 4, 2023, at 18:11, Ross Boylan wrote:
> Theory: since br0 has no associated IP address when socket creation is
> attempted, the socket creation fails.  If so, I need to delay socket
> startup until br0 has an IP4 address, but I'm not sure how to do
> that--or even if that is the problem.

This is almost certainly the cause, and the reason that the 'FreeBind' 
parameter can be set in .socket files :-)

Re: [systemd-devel] Conditionally reload a service from another service

[Kevin P. Fleming]

That's how I do it. Path units are a good solution here as they maintain loose 
coupling between the cert management and consumption.

On Mon, Jul 31, 2023, at 16:56, Max Gautier wrote:
> On Mon, Jul 31, 2023 at 03:23:26PM -0500, Ian Pilcher wrote:
>> I have created service (along with an associated timer) that checks the
>> remaining life of a TLS certificate and retrieves an updated certificate
>> from Let's Encrypt if the remaining life is too short.
>
> Is the updated certificate placed in the same file ? If so, maybe you
> could use a path unit with PathChanged=/path/to/your/cert ?
>
> -- 
> Max Gautier

[systemd-devel] Creating a man page with 'recipes' for common unit dependency combinations

[Kevin P. Fleming]

As I use systemd more and more I find myself needing to express complex 
dependencies between units. While systemd provides many 'building blocks' which 
can be combined to satisfy the requirements, determining which blocks to use, 
and the pros/cons of each combination, is non-trivial.

Attempting to find examples using search engines generally leads to Stack 
Overflow posts with no answers, or with answers which are wildly out of date, 
or are just incorrect.

I'd like to create a man page to be included with all the rest of the systemd 
man pages which details relatively common scenarios, and the various ways that 
each can be achieved using the dependency options available.

For example, right now I've got a situation with two service units, A and B. I 
want B to always be started when A is started, stopped when A is stopped, 
stopped if A stops itself, restarted if A is restarted, but otherwise left 
alone (so it should not be 'upheld' by A). I suspect this is not an uncommon 
combination, and it would be useful to be able to document one (or more) ways 
that unit dependency specifications can be used achieve this goal.

If this was contained in a man page in the systemd tree, it could then be 
updated as new versions are released with changes in dependency behavior, and 
improved when new versions offer additional dependency specifications as well. 
It would also be available on the freedesktop.org site with the rest of the man 
pages, and over time might end up being the place that most searches land.

Is this something that would be welcomed by the systemd team? Are there others 
out there listening who would be willing to help build this (contributing use 
cases, or reviewing/testing proposed solutions)? I'm happy to drive this 
effort, if so.

Re: [systemd-devel] systemd-networkd: switch between several static network setups on wired connection

[Kevin P. Fleming]

On Thu, Mar 30, 2023, at 09:35, f...@igh.de wrote:

>   [Match]
>   name = eth0
>   SSID = my-wifi
>
> would that mean, that "my-wifi" must be accessible via that interface
> (AND logic) or could that mean we configure "eth0" while "my-wifi" is
> visible on any interface (OR logic)? I had hoped for the latter. 

It is AND logic only (with some Match conditions begin negatable in their own 
right). This Match configuration would be unlikely to ever trigger, unless 
somehow SSID 'my-wifi' is reachable on interface 'eth0'.

Re: [systemd-devel] Extend systemd-resolved service to override DNS response

[Kevin P. Fleming]

On Wed, Feb 15, 2023, at 05:31, Aditya Sharma wrote:
> We were thinking of an approach where we keep on serving the last known good 
> FQDNs even after the TTL has expired (only when we are unable to communicate 
> with the resolvers). For that, we need to intercept the DNS calls and 
> maintain some kind of local cache. So, wanted to understand how we can extend 
> systemd-resolved service to serve the purpose.

systemd-resolved already has a cache, so the only thing you'd need to add is 
the ability to control whether records expire from the cache or continue to be 
served.

Re: [systemd-devel] Extend systemd-resolved service to override DNS response

[Kevin P. Fleming]

On Tue, Feb 14, 2023, at 04:04, Aditya Sharma wrote:
> Hi Kevin,
> 
> *If what you mean is that you want to serve 'stale' records from a cache when 
> their TTLs have expired and the authoritative servers which provided them are 
> not reachable, that's something that a number of existing recursive resolvers 
> are able to do and it could be logical for systemd-resolved to offer it too.
*
> We are looking to prepare a solution similar to this, to serve back records 
> for *FQDN*s in case of *timeout *from the DNS server.
> We want to understand how we can extend systemd-resolved to override response 
> from DNS server in case of timeouts/failures.

Again, you need to be very specific in your request.

systemd-resolved communicates with one or more recursive resolvers (what you 
are calling "DNS server", but that term is ambiguous). If those resolvers are 
not operational, systemd-resolved will continue serving records from its cache 
(if the cache is enabled), until their TTLs expire.

When the TTLs expire, those records in the cache become 'stale', and are 
normally purged. Your request is to have an option in systemd-resolved to *not* 
purge those records, but to continue serving them in case it is unable to 
communicate with the configured recursive resolver(s).

In your original message you referred to a 'negative response' from the "DNS 
server", but that's a completely different situation.

Re: [systemd-devel] Extend systemd-resolved service to override DNS response

[Kevin P. Fleming]

On Mon, Feb 13, 2023, at 05:38, Aditya Sharma wrote:
> Hi All,
> 
> We needed help in understanding how systemd-resolved service can be extended 
> to cache DNS responses to protect against DNS server failures.
> We were planning to maintain a cache so that we can override negative 
> responses from the DNS server and replace it with our cached last known good 
> record.

This sounds very dangerous. A 'negative' response from an authoritative DNS 
server (NXDOMAIN, for example) is authoritative and should not be overridden.

If what you mean is that you want to serve 'stale' records from a cache when 
their TTLs have expired and the authoritative servers which provided them are 
not reachable, that's something that a number of existing recursive resolvers 
are able to do and it could be logical for systemd-resolved to offer it too.

Re: [systemd-devel] service dependencies

[Kevin P. Fleming]

On Tue, Jan 10, 2023, at 06:47, Markus Rathgeb wrote:
> 
> How can I declare test2 unit section to ensure it works as expected by me?
> 
There are lots of StackOverflow posts about this... it's not as easy as it 
seems, so don't feel concerned that your attempt did not work :-)

If you are using a new enough version of systemd, the 'Upholds' and 
'PropagatesStopTo' settings for test1, referring to test2, will do what you 
want. When test1 is running, systemd will ensure that test2 is running as well 
(and will stop test1 is test2 cannot be started), and if test1 is stopped (for 
any reason) systemd will stop test2 as well.

test2 will still need Requisite and After settings referring to test1.

[systemd-devel] networkd tries only once to send IPv6 router solicitation, then never tries again

[Kevin P. Fleming]

I've just setup a new system running Debian Bookworm, so it has the
Debian systemd 251.4-3 packages installed. There's a bonded network
interface setup with systemd-networkd.

During boot, networkd attempts to send a router solicitation but fails
with "No buffer space available". I don't know why it is getting that
error, but I'd expect that to be treated as a non-permanent error, but
networkd never attempts to send a router solicitation again (unless I
use 'networkctl down  && networkctl up ', in which case the
solicitation is send and the DHCPv6 client starts and gets an
address).

Here's a portion of the log showing the behavior:

Oct 05 07:45:57 edge22-c systemd-networkd[521]: core: Received new
foreign address (configured): fe80::c71:3fff:fef0:c1fb/64 (valid
forever, preferred forever), flags: permanent, scope: link
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core: Gained IPv6LL
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core: Discovering IPv6 routers
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core: NDISC: Started
IPv6 Router Solicitation client
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core:
link_check_ready(): DHCPv4, DHCPv6, DHCP-PD or IPv4LL is enabled but
no dynamic address is assigned yet.
Oct 05 07:45:57 edge22-c systemd-networkd[521]: Sent message
type=signal sender=n/a destination=n/a
path=/org/freedesktop/network1/link/_34
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=4 reply_cookie=0 signature=sa{sv}as error-name=n/a
error-message=n/a
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core:
link_check_ready(): DHCPv4, DHCPv6, DHCP-PD or IPv4LL is enabled but
no dynamic address is assigned yet.
Oct 05 07:45:57 edge22-c systemd-networkd[521]: Sent message
type=signal sender=n/a destination=n/a path=/org/freedesktop/network1
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=5 reply_cookie=0 signature=sa{sv}as error-name=n/a
error-message=n/a
Oct 05 07:45:57 edge22-c systemd-networkd[521]: core: Received new
foreign route (configured): dst: fe80::c71:3fff:fef0:c1fb/128, src:
n/a, gw: n/a, prefsrc: n/a, scope: global, table: local(255), proto:
kernel, type: local, nexthop: 0, priority: 0, flags: n/a
Oct 05 07:45:58 edge22-c systemd-networkd[521]: core: NDISC: Error
sending Router Solicitation: No buffer space available
Oct 05 07:45:58 edge22-c systemd-networkd[521]: core: NDISC: Stopping
IPv6 Router Solicitation client
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client: DISCOVER
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
Received message from RAW socket, processing.
Oct 05 07:45:59 edge22-c systemd-networkd[521]: Ignoring DHCP option
61 while parsing.
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client: OFFER
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
REQUEST (requesting)
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
Received message from RAW socket, processing.
Oct 05 07:45:59 edge22-c systemd-networkd[521]: Ignoring DHCP option
61 while parsing.
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client: ACK
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
lease expires in 23h 59min 59s
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
T2 expires in 20h 59min 59s
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 client:
T1 expires in 12h

...

Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: DHCPv4 address
and routes set.
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core:
link_check_ready(): IPv4LL:no DHCPv4:yes DHCPv6:no DHCP-PD:no NDisc:no
Oct 05 07:45:59 edge22-c systemd-networkd[521]: core: State changed:
configuring -> configured

At the same time that the router solicitation fails the DHCPv4 client
is able to obtain an address, so the network link is fully
operational.

I'd certainly like to find out why the initial packet got "No buffer
space available", but I think it would make sense for networkd to not
treat that as a permanent condition and never try again to obtain IPv6
information.

Re: [systemd-devel] networkd D-Bus API for link up/down?

[Kevin P. Fleming]

On Thu, Sep 22, 2022 at 12:21 PM Kevin P. Fleming  wrote:

> For now I will use an OCF-style resource agent (fancy shell script)
> which uses 'networkctl' to do the work, but later I'll consider making
> something more 'native'. My primary motivation for having a 'native'
> RA is reducing the cost (time and CPU) of the regular monitoring
> operations; launching a shell script which sources many files of
> functions and has to parse 'networkctl --json' output is much more
> costly than using an ioctl to check the status of the interface
> directly. It's possible that using 'ip link' instead of 'networkctl'
> will be more efficient, so I may pursue that option too.

I ended up just cloning the existing 'iface-vlan' RA, which uses 'ip'
to do its work, and then modifying it to only manage the state of an
existing interface. It works well in my production testing, and I'm
planning on contributing it to the resource-agents repository in case
anyone else wants to do a similar thing.

Re: [systemd-devel] networkd D-Bus API for link up/down?

[Kevin P. Fleming]

On Thu, Sep 22, 2022 at 9:45 AM Lennart Poettering
 wrote:
>
> On Mi, 21.09.22 06:48, Kevin P. Fleming (ke...@km6g.us) wrote:
>
> > When the D-Bus API for systemd-networkd was added there were
> > indications that it could be used for bringing links up and down.
> > However, when I review the API docs at:
> >
> > https://www.freedesktop.org/software/systemd/man/org.freedesktop.network1.html#
> >
> > I don't see any methods for doing those operations. networkctl uses
> > netlink messages for these operations as well.
> >
> > I want to create a cluster resource agent for Pacemaker which can
> > manage networkd links, and using D-Bus would be easier than using
> > netlink since there is already D-Bus support in the resource agent for
> > systemd units.
>
> This is currently not available. But do note that you can use
> ActivationPolicy= in a .network file and then simply toggle the IFF_UP flag
> on the net device, and networkd is happy.
>
> If you don#t want to bother with rtnetlink for that you could even use
> the old BSD ioctls, i.e. SIOCSIFFLAGS.

Thanks! I'm already using ActivationPolicy=manual in the .network file
since networkd can't know when the interface should be up or down.

For now I will use an OCF-style resource agent (fancy shell script)
which uses 'networkctl' to do the work, but later I'll consider making
something more 'native'. My primary motivation for having a 'native'
RA is reducing the cost (time and CPU) of the regular monitoring
operations; launching a shell script which sources many files of
functions and has to parse 'networkctl --json' output is much more
costly than using an ioctl to check the status of the interface
directly. It's possible that using 'ip link' instead of 'networkctl'
will be more efficient, so I may pursue that option too.

[systemd-devel] networkd D-Bus API for link up/down?

[Kevin P. Fleming]

When the D-Bus API for systemd-networkd was added there were
indications that it could be used for bringing links up and down.
However, when I review the API docs at:

https://www.freedesktop.org/software/systemd/man/org.freedesktop.network1.html#

I don't see any methods for doing those operations. networkctl uses
netlink messages for these operations as well.

I want to create a cluster resource agent for Pacemaker which can
manage networkd links, and using D-Bus would be easier than using
netlink since there is already D-Bus support in the resource agent for
systemd units.

Re: [systemd-devel] networkd : ipv6 prefix delegation

[Kevin P. Fleming]

On Mon, Sep 5, 2022 at 1:45 PM Arian van Putten
 wrote:
>
> Just thinking out loud here but aren't RA messages are sent as link local 
> multicast messages? How can it send them if you disable link local addressing?

Yes, this. There's no benefit to disabling link-local addressing, and
doing so can definitely break other IPv6 features. I've never seen an
explicitly-configured link-local address before, but I'd be really
surprised if it worked as a replacement for the
automatically-generated link-local address.

Re: [systemd-devel] systemd-nspawn container not starting on RHEL9.0

[Kevin P. Fleming]

On Tue, Aug 9, 2022 at 12:43 PM Thomas Archambault
 wrote:
> One obvious issue is the non-zero return from an ioctl call with the
> BTRFS_IOC_SUBVOL_CREATE arg at line 410, in the snippet below from my
> RHEL9.0 strace capture; this is occurring right after the initial blast
> of debug log messages. I'm trying to get a stack trace for that error
> currently.
>
>
> 410-2064 ioctl(5, BTRFS_IOC_SUBVOL_CREATE, {fd=0,
> name=".#machine.c8578d59f810b73d"}) = -1 ENOTTY (Inappropriate ioctl for
> device)

Since you are using XFS and not Btrfs this seems like an expected result.

Re: [systemd-devel] How can we debug systemd-gpt-auto-generator failures?

[Kevin P. Fleming]

On Sat, Jul 30, 2022 at 8:45 AM Chris Murphy  wrote:
>
>
>
> On Thu, Jul 28, 2022, at 6:50 AM, Kevin P. Fleming wrote:
> > I've got two systems that report a failure (exit code 1) every time
> > systemd-gpt-auto-generator is run. There are a small number of reports
> > of this affecting other users too:
> >
> > https://bugs.archlinux.org/task/73168
> >
> > This *may* be related to the use of ZFS, although I've got a
> > half-dozen systems using ZFS and only two of them have this issue.
>
> Are the two with the problem multiple device ZFS? And the rest are single 
> device ZFS?

None of my multiple-device ZFS systems experience this problem. These
two are single-device, but there are also other single-device systems
that don't experience this problem.

The issue that Lennart linked to appears to be the solution, but it's
not important enough for me to ask for it to backported into the
Debian Bullseye systemd packages.

Re: [systemd-devel] How can we debug systemd-gpt-auto-generator failures?

[Kevin P. Fleming]

Thanks! I hadn't paid any attention to that issue since I'm not using
btrfs, but it seems that the root cause is the same.

On Thu, Jul 28, 2022 at 9:31 AM Lennart Poettering
 wrote:
>
> On Do, 28.07.22 07:40, Kevin P. Fleming (ke...@km6g.us) wrote:
>
> > Thanks for that, it did indeed produce some output, but unfortunately
> > it doesn't seem to lead anywhere specific :-)
> >
> > root@edge21-a:~# SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_TARGET=console
> > LIBBLKID_DEBUG=all
> > /usr/lib/systemd/system-generators/systemd-gpt-auto-generator
> > Found container virtualization none.
> > Disabling root partition auto-detection, root= is defined.
> > Disabling root partition auto-detection, root= is defined.
> > Failed to open device: No such device
> >
> > Adding strace to the command provides something more useful:
> >
> > openat(AT_FDCWD, "/", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = 3
> > openat(3, "sys", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 4
> > fstat(4, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
> > close(3)= 0
> > openat(4, "dev", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
> > fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > close(4)= 0
> > openat(3, "block", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 4
> > fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
> > close(3)= 0
> > openat(4, "0:0", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = -1 ENOENT (No
> > such file or directory)
> > close(4)
> >
> > So it's trying to open() /sys/dev/block/0:0, but my system does not
> > have that device file. The only files in /sys/dev/block are 8:0
> > through 8:3.
>
> → https://github.com/systemd/systemd/issues/22504
>
> Lennart
>
> --
> Lennart Poettering, Berlin

Re: [systemd-devel] How can we debug systemd-gpt-auto-generator failures?

[Kevin P. Fleming]

Thanks for that, it did indeed produce some output, but unfortunately
it doesn't seem to lead anywhere specific :-)

root@edge21-a:~# SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_TARGET=console
LIBBLKID_DEBUG=all
/usr/lib/systemd/system-generators/systemd-gpt-auto-generator
Found container virtualization none.
Disabling root partition auto-detection, root= is defined.
Disabling root partition auto-detection, root= is defined.
Failed to open device: No such device

Adding strace to the command provides something more useful:

openat(AT_FDCWD, "/", O_RDONLY|O_CLOEXEC|O_PATH|O_DIRECTORY) = 3
openat(3, "sys", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 4
fstat(4, {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
close(3)= 0
openat(4, "dev", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
close(4)= 0
openat(3, "block", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
close(3)= 0
openat(4, "0:0", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = -1 ENOENT (No
such file or directory)
close(4)

So it's trying to open() /sys/dev/block/0:0, but my system does not
have that device file. The only files in /sys/dev/block are 8:0
through 8:3.

On Thu, Jul 28, 2022 at 7:17 AM Mantas Mikulėnas  wrote:
>
> On Thu, Jul 28, 2022 at 1:51 PM Kevin P. Fleming  wrote:
>>
>> I've got two systems that report a failure (exit code 1) every time
>> systemd-gpt-auto-generator is run. There are a small number of reports
>> of this affecting other users too:
>>
>> https://bugs.archlinux.org/task/73168
>>
>> This *may* be related to the use of ZFS, although I've got a
>> half-dozen systems using ZFS and only two of them have this issue.
>>
>> Running the generator from the command line also produces exit code 1,
>> but doesn't produce any output. is there any practical way to debug
>> this failure?
>
>
> Start with SYSTEMD_LOG_LEVEL=debug (and SYSTEMD_LOG_TARGET=console if you 
> want to run the tool from CLI, otherwise it logs to journal). If it only 
> fails as part of a daemon-reexec, `systemctl set-environment` (not sure if 
> `systemctl log-level` has any effect on non-pid1 processes). Since it uses 
> libblkid, there's also LIBBLKID_DEBUG=all.
>
> --
> Mantas Mikulėnas

[systemd-devel] How can we debug systemd-gpt-auto-generator failures?

[Kevin P. Fleming]

I've got two systems that report a failure (exit code 1) every time
systemd-gpt-auto-generator is run. There are a small number of reports
of this affecting other users too:

https://bugs.archlinux.org/task/73168

This *may* be related to the use of ZFS, although I've got a
half-dozen systems using ZFS and only two of them have this issue.

Running the generator from the command line also produces exit code 1,
but doesn't produce any output. is there any practical way to debug
this failure?

[systemd-devel] nspawn '-U' overridden by setting PrivateUsersChown

[Kevin P. Fleming]

After using nspawn for a couple of years I finally realized that I
wasn't getting the PrivateUsersChown behavior that I expected, and
looked into it.

I'm using systemd 247 on Debian, which has the standard nspawn
template service unit file which includes '-U' (and
'--settings=override'). According to the manpage, this means that if
user namespacing is supported by the kernel (which it is in the
Bullseye 5.10 kernel), this is equivalent to specifying
'--private-users=pick --private-users-chown'. This was the behavior I
wanted, but it wasn't happening, all of the container filesystems had
UID/GIDs that matched the host ranges.

I do not remember why, but I was creating nspawn settings files (in
/etc/systemd/nspawn) for each container which included (among other
things) 'PrivateUsersChown=yes' in their 'Files' section. I assumed
this would not matter, since that setting was included in the '-U'
command-line argument for nspawn... but I was wrong.

It seems that including this causes nspawn to ignore the '-U'
command-line argument completely. Removing it, or adding
'PrivateUsers=pick' to the 'Exec' section of the settings file,
produces the desired result, so I've removed it.

I suspect this is just a matter of documentation, to let the user know
that if they specify any PrivateUsers-related options in the settings
file then '-U' will be ignored, even if the settings they specify are
the same ones that '-U' does.

Just for completeness, I tested this on Debian Bookworm as well, which
has systemd 251.7, and the behavior is unchanged.

Re: [systemd-devel] Waiting for network routes to appear

[Kevin P. Fleming]

On Wed, Jun 15, 2022 at 5:03 PM Barry  wrote:
> To be robust why not make the services recover from network issues?
> Then you do not need to care about the routes.
> Of course you will need to know if services have outages.
>
> Even if a route was working at some point what do you do if the route
> goes down later?

While I would love to do that, the services in question aren't my
code, and I can't easily/quickly change their behavior. At the moment
I have systemd setup to allow them to restart a large number of times
so that they'll eventually start up and connect, and of course if they
fail during operation they'll get restarted too. I want to wait for
the routes just to improve the elegance of the installation, not its
function :-)

Re: [systemd-devel] Waiting for network routes to appear

[Kevin P. Fleming]

Thanks, that pretty much matches my thinking. There's a lot of
potential complexity here.

Another way to approach this would be to specify addresses (endpoints)
that must be reachable (for some definition of reachable: ICMP ping,
TCP open, etc.), and then the monitoring tool would run an initial set
of reachability checks. If any are not reachable, it would monitor
netlink to see when new routes appear, and then retry the checks. This
addresses the changes in the structure of the routes, as it doesn't
matter *how* the endpoint is reachable, as long as it is reachable.
I'm probably going to implement my custom tool in this fashion, as I
think it's a better model overall.

On Wed, Jun 15, 2022 at 9:35 AM Mantas Mikulėnas  wrote:
>
> I think it's better to use a custom tool. RequiresMountsFor relies on knowing 
> the exact mount points from the beginning and just waiting for them to be 
> done – but that might not exactly match networking, where you might have two 
> /24 routes today and a /23 tomorrow, so you can't exactly predefine that in 
> units.
>
> A custom tool could more easily express logic like waiting for any route 
> matching the specified address, or any non-/0 route, or any route through the 
> specified interfaces.
>
> (If you're in this situation, you probably also have several routing tables, 
> and perhaps a ton of routes. I would not want all that memory usage in pid 1 
> – already went through this for systemd-networkd, and then once more for 
> nss_myhostname...)
>
> On Wed, Jun 15, 2022, 14:32 Kevin P. Fleming  wrote:
>>
>> I've got a number of systems that use BIRD to learn the routes
>> available on their networks, and as a result some services on those
>> systems attempt to start up before the routes have been learned. If
>> those services attempt to make network connections (even just DNS
>> queries), they will fail, and that's unpleasant.
>>
>> I can't use existing systemd facilities to make these services wait,
>> because there's no mechanism available for BIRD to indicate that any
>> specific route has been learned, or a way to configure a service to
>> wait for a specific route.
>>
>> I'm considering just writing a smallish Python program which will
>> accept (via configuration) a list of routes, and will listen to
>> netlink to wait for all of those routes to appear. I'd then make my
>> services dependent on this service reporting success. However, since
>> networkd already listens to netlink, it would certainly be possible
>> for it to provide this facility in some way.
>>
>> If you'll pardon the analogy, I'm thinking of something like
>> RequiresMountsFor=, which makes service startup wait until mount units
>> have succeeded. Of course following this analogy we'd end up creating
>> the concept of a 'route unit', and I'm not sure that's really the
>> right thing to do here.
>>
>> Is it worth trying to design some way for networkd to provide this
>> facility? if not, I'll just continue down the road of doing this
>> outside of systemd proper.

[systemd-devel] Waiting for network routes to appear

[Kevin P. Fleming]

I've got a number of systems that use BIRD to learn the routes
available on their networks, and as a result some services on those
systems attempt to start up before the routes have been learned. If
those services attempt to make network connections (even just DNS
queries), they will fail, and that's unpleasant.

I can't use existing systemd facilities to make these services wait,
because there's no mechanism available for BIRD to indicate that any
specific route has been learned, or a way to configure a service to
wait for a specific route.

I'm considering just writing a smallish Python program which will
accept (via configuration) a list of routes, and will listen to
netlink to wait for all of those routes to appear. I'd then make my
services dependent on this service reporting success. However, since
networkd already listens to netlink, it would certainly be possible
for it to provide this facility in some way.

If you'll pardon the analogy, I'm thinking of something like
RequiresMountsFor=, which makes service startup wait until mount units
have succeeded. Of course following this analogy we'd end up creating
the concept of a 'route unit', and I'm not sure that's really the
right thing to do here.

Is it worth trying to design some way for networkd to provide this
facility? if not, I'll just continue down the road of doing this
outside of systemd proper.

Re: [systemd-devel] Starting one service when another one starts

[Kevin P. Fleming]

This sort of behavior has been a long-standing desire of many systemd
users, and you can find probably thousands of blog/forum/SO posts
about it. As Andrei said, the names of the dependencies in systemd
units might appear to be the behavior you want, but they aren't.

If you have a situation where service B must always be running when
service A is running, and never when service A is not running, a
combination of "Upholds" and "PropagatesStopTo" will do that, although
you'll need very recent systemd to have these available.

On Sat, Apr 9, 2022 at 1:17 AM Andrei Borzenkov  wrote:
>
> On 08.04.2022 23:35, Nick Howitt wrote:
> > Sorry, for the delay. Big internet outage.
> >
> > On 08/04/2022 15:15, Andrei Borzenkov wrote:
> >>
> >> On 08.04.2022 14:54, Nick Howitt wrote:
> >>> Hi,
> >>> I apologise if this is not the right place for user help. If it is not,
> >>> please point me to the best place.
> >>>
> >>> I am trying to start a service (clearshare-scheduler) when another
> >>> service (siad) starts. Clearshare-scheduler is an odd service. When you
> >>> start it it may run for ages (days+) or it may terminate immediately so
> >>> I have set it up as a oneshot:
> >>>
> > clearshare-scheduler.service
> >>> [Unit]
> >>> Description=Clearshare Scheduler
> >>> PartOf=siad.service
> >>> After=siad.service
> >>>
> >>> [Service]
> >>> Type=oneshot
> >>> Environment="TERM=dumb"
> >>> ExecStartPre=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> >>> ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from
> >>> systemd" >> /var/log/scheduler.log
> >>> ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null
> >>> ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> >>>
> >>> [Install]
> >>> WantedBy=multi-user.target
> >>>
> >>> The siad service looks like:
> >>>
> > siad.service
> >>> [Unit]
> >>> Description=Siad
> >>> After=syslog.target network.target clearsync.service
> >>>
> >>> [Service]
> >>> Type=simple
> >>> OOMScoreAdjust=500
> >>> PIDFile=/var/run/siad.pid
> >>> EnvironmentFile=/etc/sysconfig/siad
> >>> Environment="SIA_DATA_DIR=/var/lib/siad-data"
> >>> ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh
> >>> ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid
> >>> ExecStart=/usr/bin/siad $EXTRA_ARGS
> >>> ExecStop=/usr/bin/siac stop
> >>> WorkingDirectory=/var/lib/sia/
> >>> ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad >
> >>> /var/run/siad.pid'
> >>>
> >>> [Install]
> >>> WantedBy=multi-user.target
> >>>
> >>
> >> You do not show actual unit names which makes it rather difficult to 
> >> follow.
> > Done. See above
> >>
> >>> A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as
> >>> one of its properties but, in reverse, "systemctl show siad" does not
> >>> list the corresponding ConsistsOf property.
> >>>
> >>> When I start siad, nothing happens to the clearshare-scheduler service.
> >>
> >> Why do you expect to happen? There is no Wants or Requires in the unit
> >> that is /probably/ siad.service so request to start siad.service will
> >> not pull in any additional units.
> > Perhaps I have misunderstood, but from the documentation I understood
> > you could PartOf in force (in this case) clearshare-scheduler.service to
> > respond when siad.service was stopped or started. Have I misunderstood
> > the docs? I am hoping to not do any changes to the siad.service.
> >
>
> Documentation for PartOf says "limited to stopping and restarting of
> units". Nothing about "starting". PartOf complements normal startup
> dependencies, not replaces them. And yes, this is confusing, as are the
> names of almost any systemd dependency which mean something entirely
> different from what these names imply in English.
>
> You can add WantedBy=siad.service to [Install] section of
> clearshare-scheduler.service. In general you can always extend Wants by
> manually creating necessary links. This does not require you to edit
> unit definition itself. You can also create drop-in (although I am not
> sure whether they are already supported in your systemd version).
>
> > As an alternative, which does affect the siad.service, is there any way
> > I can run the clearshare-scheduler.sh script from the siad.service? I
> > have tried starting it as a ExecStartPost, but it does not appear to
> > work if the script does not exit immediately. If it runs for a while,
> > then systemd says siad has failed to start.
>
> You can increase TimeoutStartSec.
>
> > I've tried launching it with
> > ExecStartPost=-/usr/sbin/clearshare-scheduler.sh
>
> "-" affects command that completed with failure status, in your case
> command does not complete so this does not have any effect.
>
> > and
> > ExecStartPost=-/usr/sbin/clearshare-scheduler.sh &
> > and
> > ExecStartPost=-/usr/bin/nohup /usr/sbin/clearshare-scheduler.sh &
> >
>
> sytsemd is not shell, what made you think this would work? If you want
> to use shell syntax, you need to invoke shell
>
> /bin/sh 

[systemd-devel] Which distributions copy systemd-networkd 'link' files into the initramfs?

[Kevin P. Fleming]

Is this just a Debian (and derivatives) feature, or more common?

I just spent nearly an hour trying to figure out why the link file
changes I'd made on a system were not working properly, and this was
the cause. I even ran 'networkctl status' on an interface that should
no longer exist, and it reported a 'Link File' path that did not
exist... because it *used* to exist (in /etc, not /usr), and had been
copied into the initramfs.

At a minimum, I'd like to suggest to the relevant distros that they
modify systemd.link(5) to clearly indicate that this behavior exists
and that any changes to link files must be accompanied by an initramfs
update or the behavior on the next system boot may result in a
non-functional network.

Re: [systemd-devel] Have I got circular dependencies?

[Kevin P. Fleming]

Indeed! While it will take some time, I can highly recommend reading
the entirety of the various man pages: systemd.unit, systemd.service,
systemd.target, systemd.special. I've been able to take advantage of
many 'not obvious' features by doing that.

On Mon, Jan 24, 2022 at 7:21 AM Wols Lists  wrote:
>
> On 24/01/2022 11:08, Kevin P. Fleming wrote:
> > According to 'man systemd.unit' it goes in the '[Unit]' section, like
> > all other dependency statements.
>
> Thank you very much. The usual problem of "where's the docu I'm looking
> for?" :-)
>
> Cheers,
> Wol
> >
> > On Sun, Jan 23, 2022 at 3:15 PM Wols Lists  wrote:
> >>
> >> On 23/01/2022 19:44, Andrei Borzenkov wrote:
> >>> Where dependency to /home comes from? It is not in your unit file.
> >>
> >> If it thinks my unit depends on /home, that's wrong. /home comes from
> >> fstab, and the partition is not available until AFTER my service has
> >> run. Home is on an lv, which is on raid, which is on dm-integrity, which
> >> isn't available until my service has turned it on ...
> >>>
> >>> Otherwise normal services are ordered by default after sysinit.target and
> >>> local file systems are ordered before sysinit.target so you have loop. Add
> >>> DefaultDependencies=no to your service definition.
> >>
> >> Thanks. I presume that goes in the [Install] section? I can find plenty
> >> of stuff telling me WHAT DefaultDependencies is, but nothing I can
> >> understand that tells me WHERE it goes.
> >>
> >> Thanks,
> >> Cheers,
> >> Wol
>

Re: [systemd-devel] Have I got circular dependencies?

[Kevin P. Fleming]

According to 'man systemd.unit' it goes in the '[Unit]' section, like
all other dependency statements.

On Sun, Jan 23, 2022 at 3:15 PM Wols Lists  wrote:
>
> On 23/01/2022 19:44, Andrei Borzenkov wrote:
> > Where dependency to /home comes from? It is not in your unit file.
>
> If it thinks my unit depends on /home, that's wrong. /home comes from
> fstab, and the partition is not available until AFTER my service has
> run. Home is on an lv, which is on raid, which is on dm-integrity, which
> isn't available until my service has turned it on ...
> >
> > Otherwise normal services are ordered by default after sysinit.target and
> > local file systems are ordered before sysinit.target so you have loop. Add
> > DefaultDependencies=no to your service definition.
>
> Thanks. I presume that goes in the [Install] section? I can find plenty
> of stuff telling me WHAT DefaultDependencies is, but nothing I can
> understand that tells me WHERE it goes.
>
> Thanks,
> Cheers,
> Wol

[systemd-devel] systemd-networkd 'policy rule' errors in journal

[Kevin P. Fleming]

On my two systems that are running systemd 249.5-1 (Debian sid
packages), I see this message in the journal once for each network
interface that systemd-networkd manages:

Could not drop routing policy rule: No such file or directory

I don't have any routing policies configured on the systems, so I
can't figure out what is causing this.

Re: [systemd-devel] What is the recommended way of announcing a TCP port?

[Kevin P. Fleming]

You might consider having systemd itself create the listening sockets
and then pass them into the service; if you did that, then systemd
would already know the port number that was allocated for the socket.

On Mon, Jun 14, 2021 at 9:17 PM John Ioannidis  wrote:
>
> I have an instanced service that gets started and stopped by another service: 
> alice.service runs the equivalent of systemsctl start alice@foo.service, 
> systemctl start alice@bar.service, systemctl stop alice@cat.service, and so 
> on.
> Each of the instanced services runs a little http service so its status can 
> be monitored, metrics scraped, etc. The tcp port on which that service runs 
> is just whatever the kernel allocated. I want to export that port number so 
> other processes can find it and use it, for example, by doing the equivalent 
> of systemctl list-units | grep alice@ so they find which instances are 
> actually running, and then going about finding the corresponding ports.
>
> I can think of a number of ad hoc ways:
>
> * they can write the port number in a file like /run/alice/foo.port, 
> /run/alice/bar.port, and whoever is interested can go read those files, in 
> the same way that we use .pid files.
> * They can use systemd-notify to export it as "Status"
> * Using a service discovery mechanism would be an overkill, especially since 
> whatever is actually talking to those ports is on the same host as the 
> services themselves, but that's also a possibility.
>
> Is there a systemd-native way of accomplishing this? It would be nice if it 
> were possible to have user-defined properties that could be set with 
> systemctl set-property, but that is not the case.
>
> Thanks
>
> /ji
> ___
> 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] use RTC date/time to set system date time

[Kevin P. Fleming]

It's fairly simple to add a one-shot service unit to use 'hwclock' to
read from the RTC and set the kernel's real-time clock. I do this on
my RPis which use modules for their RTCs.

On Mon, Mar 1, 2021 at 9:02 AM Michał Zegan  wrote:
>
> Someone should really find a way to make it cooperate well with modular
> rtcs.
> It's popping up over and over and over and over again and no one is/will
> build all rtc drivers into the kernel.
>
> W dniu 01.03.2021 o 13:04, Mantas Mikulėnas pisze:
> > Normally I think systemd expects the kernel to do this on its own.
> >
> > On Mon, Mar 1, 2021, 12:31 Belisko Marek  > > wrote:
> >
> > Hi,
> >
> > I have a case when a board boots without network connection but RTC
> > have the correct date/time. Does systemd use RTC date/time to set
> > systemd time or it needs to be done manually?
> >
> > Thanks and regards,
> >
> > marek
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com 
> > ___
> > 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
> >
>
> ___
> 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] timesyncd log messages galore

[Kevin P. Fleming]

Agreed, I run timesyncd on 20+ machines on a bunch of VLANs that are
all IPv6-enabled with RAs being used, and have not seen this symptom.

On Thu, Feb 11, 2021 at 11:23 AM Mantas Mikulėnas  wrote:
>
> On Thu, Feb 11, 2021 at 6:07 PM Ede Wolf  wrote:
>>
>> Thanks. Indeed, stopping radvd made these messages stop appearing.
>> Now I am no IPv6 guru, but having routeradvertisments is not too
>> uncommon, to the best of my knowledge.
>
>
> RAs shouldn't be extremely frequent. An hour is a common interval for 
> periodic RAs -- certainly not minutes or seconds.
>
> OTOH, I am not seeing any such messages on any of my IPv6 hosts using 
> timesyncd. There is a burst of "network changed" messages on boot, presumably 
> in response to bridges and tunnels being set up, but the daemon stays quiet 
> afterwards. Currently it has recorded 1.988s total CPU usage after 12 days of 
> uptime.
>
>>
>> So the punchline is, that timesynd is not really usable with ipv6
>> networks? Am I getting that correct?
>
>
> No, sounds more like it's just not really usable with *your* IPv6 network.
>
> --
> Mantas Mikulėnas
> ___
> 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] nspawn+networkd sometimes fail to configure IPv6 properly

[Kevin P. Fleming]

While debugging a different problem (which I'll report in an issue in
the GitHub repo), I found something which appears to be the underlying
cause.

I rebooted a machine which has five nspawn containers, all configured
identically for networking (except for addresses, of course).
Immediately after the boot, 'machinectl list' shows all five
containers running, and all five are accessible over IPv4.

However, only two are accessible over IPv6, and:

---
root@net20:~# ip neigh show proxy
2607:5300:203:5215::1 dev ve-mail20  proxy
2607:5300:203:5215::1 dev ve-diw20  proxy
---

Only two are listed with proxy addresses for the host on their veth
devices; these are the two that are accessible.

---
root@net20:~# machinectl stop ns3
root@net20:~# machinectl start ns3
root@net20:~# ip neigh show proxy
2607:5300:203:5215::1 dev ve-ns3  proxy
2607:5300:203:5215::1 dev ve-mail20  proxy
2607:5300:203:5215::1 dev ve-diw20  proxy
---

After a stop/start of the 'ns3' container, it now has the necessary
proxy address on its veth device, and it is accessible over IPv6.

---
root@net20:~# machinectl stop matrix20
root@net20:~# machinectl start matrix20
root@net20:~# ip neigh show proxy
2607:5300:203:5215::1 dev ve-matrix20  proxy
2607:5300:203:5215::1 dev ve-ns3  proxy
2607:5300:203:5215::1 dev ve-mail20  proxy
2607:5300:203:5215::1 dev ve-diw20  proxy
root@net20:~# machinectl stop ldl20
root@net20:~# machinectl start ldl20
root@net20:~# ip neigh show proxy
2607:5300:203:5215::1 dev ve-ldl20  proxy
2607:5300:203:5215::1 dev ve-matrix20  proxy
2607:5300:203:5215::1 dev ve-ns3  proxy
2607:5300:203:5215::1 dev ve-mail20  proxy
2607:5300:203:5215::1 dev ve-diw20  proxy
---

Same results for stop/start of the remaining two containers; they get
the necessary proxy address, and become reachable.

I've got DEBUG logging enabled for systemd-networkd but there is no
evidence of any problem related to proxy address addition
(https://gist.github.com/kpfleming/4b6c721edaf9d2ff4a24dadbb002fb0c).

I think the next step is going to be building systemd from source to
verify that the Debian 247.2 packages aren't at fault, and then adding
more debugging output in the necessary places.

On Sun, Jan 24, 2021 at 10:14 AM Kevin P. Fleming  wrote:
>
> I've got three systems which host nspawn-based containers, using
> networkd for network configuration on both the host and inside the
> containers. All of the systems are running Debian systemd packages
> (some version 241 (buster) and some 247.2 (bullseye)). The behavior
> has been seen with kernels 5.4, 5.9, and 5.10 (both Debian kernel
> packages and a hand-built vanilla kernel package). There are no
> firewalls in use.
>
> An example configuration:
>
> host - /etc/systemd/nspawn/mqtt20.nspawn
> 
> [Files]
> PrivateUsersChown=yes
> [Network]
> VirtualEthernetExtra=mqtt20:srv
>
> host - /etc/systemd/network/mqtt20.network
> ---
> [Match]
> Name=mqtt20
>
> [Network]
> Address=192.168.254.108/32
> Address=fd80:ae6b:5f43:254::108/128
>
> [Route]
> Destination=192.168.64.108
> Scope=link
>
> [Route]
> Destination=2001:470:8afe:64::108
>
> [Route]
> Destination=fd80:ae6b:5f43:64::108
>
> container - /etc/systemd/network/primary.network
> ---
> [Match]
> Name=srv
>
> [Network]
> Address=192.168.64.108/32
> Address=2001:470:8afe:64::108/128
> Address=fd80:ae6b:5f43:64::108/128
> DNS=fd80:ae6b:5f43:1::8
>
> [Route]
> Destination=192.168.254.108/32
> Scope=link
>
> [Route]
> Gateway=192.168.254.108
> Destination=0.0.0.0/0
>
> [Route]
> Destination=fd80:ae6b:5f43:254::108/128
>
> [Route]
> Gateway=fd80:ae6b:5f43:254::108
> Destination=::/0
>
> ---
>
> Layer 3 networking is used, on virtual Ethernet devices.
>
> Sometimes, after a system startup, some of the containers are not
> reachable over IPv6. When this happens, their IPv4 connectivity is
> fine. Running 'machinectl stop ' followed by 'machinectl start '
> always cures the problem.
>
> When a container is in this state, 'ip link ls' and 'ip addr ls' on
> the host and in the container don't display anything out of the
> ordinary (the details match those of another container on the same
> host which works properly).
>
> I've run tcpdump on the veth device for a broken container and then
> sent ICMPv6 pings from another system on the network; what I see is
> that the host sends IPv6 Neighbor Solicitation requests on the veth
> device to discover the container's layer 2 address, but no replies are
> sent. Running tcpdump inside the container shows the same thing; NS is
> received, but no reply is sent.
>
> It's as if the IPv6 stack in the container's network namespace is
> just... not listening at all.
>
> Can anyone suggest ways to troubleshoot this beyond the simple things
> I've listed above?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] nspawn+networkd sometimes fail to configure IPv6 properly

[Kevin P. Fleming]

I've got three systems which host nspawn-based containers, using
networkd for network configuration on both the host and inside the
containers. All of the systems are running Debian systemd packages
(some version 241 (buster) and some 247.2 (bullseye)). The behavior
has been seen with kernels 5.4, 5.9, and 5.10 (both Debian kernel
packages and a hand-built vanilla kernel package). There are no
firewalls in use.

An example configuration:

host - /etc/systemd/nspawn/mqtt20.nspawn

[Files]
PrivateUsersChown=yes
[Network]
VirtualEthernetExtra=mqtt20:srv

host - /etc/systemd/network/mqtt20.network
---
[Match]
Name=mqtt20

[Network]
Address=192.168.254.108/32
Address=fd80:ae6b:5f43:254::108/128

[Route]
Destination=192.168.64.108
Scope=link

[Route]
Destination=2001:470:8afe:64::108

[Route]
Destination=fd80:ae6b:5f43:64::108

container - /etc/systemd/network/primary.network
---
[Match]
Name=srv

[Network]
Address=192.168.64.108/32
Address=2001:470:8afe:64::108/128
Address=fd80:ae6b:5f43:64::108/128
DNS=fd80:ae6b:5f43:1::8

[Route]
Destination=192.168.254.108/32
Scope=link

[Route]
Gateway=192.168.254.108
Destination=0.0.0.0/0

[Route]
Destination=fd80:ae6b:5f43:254::108/128

[Route]
Gateway=fd80:ae6b:5f43:254::108
Destination=::/0

---

Layer 3 networking is used, on virtual Ethernet devices.

Sometimes, after a system startup, some of the containers are not
reachable over IPv6. When this happens, their IPv4 connectivity is
fine. Running 'machinectl stop ' followed by 'machinectl start '
always cures the problem.

When a container is in this state, 'ip link ls' and 'ip addr ls' on
the host and in the container don't display anything out of the
ordinary (the details match those of another container on the same
host which works properly).

I've run tcpdump on the veth device for a broken container and then
sent ICMPv6 pings from another system on the network; what I see is
that the host sends IPv6 Neighbor Solicitation requests on the veth
device to discover the container's layer 2 address, but no replies are
sent. Running tcpdump inside the container shows the same thing; NS is
received, but no reply is sent.

It's as if the IPv6 stack in the container's network namespace is
just... not listening at all.

Can anyone suggest ways to troubleshoot this beyond the simple things
I've listed above?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd setting up two Microchip switch ports as individual network interfaces and then bonding them

[Kevin P. Fleming]

While I can't comment on the specifics of configuring systemd-networkd
to use ports through DSA (although the linked GitHub issue shows that
it can be done), I really doubt you are going to be able to
successfully bond any group of such ports, because they all have the
same MAC address. In your proposed configuration, you have a NIC
connected to a switch (internal to your system), which would then have
multiple ports connected to *another* switch. Unless the switches
involved support STP or some other loop-avoidance mechanism, you will
get a switching loop in this configuration.

Connecting multiple ports between two switches requires cooperation in
the switches (STP, or LACP, or something else).

On Tue, Oct 13, 2020 at 8:56 AM Brian Hutchinson  wrote:
>
> Hi,
>
> I have my device tree exposing two Microchip KSZ9567 switch ports.  I need to 
> use them as individual NIC's.
>
> I've tested the DSA driver as individual nics and they work fine.  I do this 
> with:
>
> ip addr add 192.168.0.4/24 dev lan1
> ip addr add 192.168.2.4/24 dev lan2
>
> ip link set eth0 up
> ip link set lan1 up
> ip link set lan2 up
>
> ... but I have no clue how to do this with /etc/systemd/network scripts
>
> The above was just testing/verifying my device tree and DSA driver and a step 
> toward real goal.  Once I get two of the switch ports (the only two the 
> hardware brings out) to act as individual NIC's my next goal is to bond them 
> for redundancy.
>
> I really have no clue how to do that and have struggled to even uncover 
> relevant information.  The closest thing I've found is:
>
> A discussion of DSA issues
> https://github.com/systemd/systemd/issues/7478
>
> Bonding but doesn't look like my DSA case.
> https://kerlilow.me/blog/setting-up-systemd-networkd-with-bonding/#setting-up-the-bond
>
> I tried the above link and it looked like all I did was create a switch loop 
> as the LED's on my switch went crazy when I connected both of my ethernet 
> ports.
>
> Anyone have experience with systemd and DSA and bonding?
>
> Regards,
>
> Brian
> ___
> 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] spurious failures of resolved

[Kevin P. Fleming]

If you are using NetworkManager to manage your links, then you need to
convince it to stop providing the DNS resolver information. You can't
use a systemd-networkd file to override this, as networkd is not
managing the links.

On Thu, Sep 24, 2020 at 11:10 AM Roman Odaisky  wrote:
>
> Hi,
>
> > You have "~." for the global config, but your Networkmanager or something
> > also sets "~." for each of your two links, so all those settings are back
> > to being the same priority again.
>
> Thanks for shedding some light on this. Is this the intended way network
> managers are supposed to interact with systemd or is it a bug in NM?
>
> If I really want to use a custom DNS server for everything, do I understand
> correctly that in addition to Domains=~. I need a network file along the lines
> of
>
> [Match]
> Name=*
>
> [DHCPv4]
> UseDNS=no
>
> ?
>
> --
> WBR
> Roman.
>
>
> ___
> 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] spurious failures of resolved

[Kevin P. Fleming]

In your network configuration for the faulty link you can just set
"UseDNS=no" in the 'DHCPv4' section and then resolved will not even
try to use those resolvers.

On Thu, Sep 24, 2020 at 7:45 AM Roman Odaisky  wrote:
>
> Hi,
>
> I have the following resolved configuration:
>
> [Resolve]
> DNS=8.8.8.8 8.8.4.4
> Domains=~.
>
> and the following resolvectl output:
>
> Link 76 (usb0)
>   Current Scopes: DNS
> DefaultRoute setting: yes
>LLMNR setting: yes
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>   DNSSEC setting: no
> DNSSEC supported: no
>   Current DNS Server: 192.168.42.129
>  DNS Servers: 192.168.42.129
>   DNS Domain: ~.
>
> Link 2 (wlp59s0)
>   Current Scopes: DNS
> DefaultRoute setting: yes
>LLMNR setting: yes
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>   DNSSEC setting: no
> DNSSEC supported: no
>   Current DNS Server: 
>  DNS Servers: 
>   
>   DNS Domain: ~.
>
> The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve
> resorted to USB tethering). The DNS servers provided by DHCP for that link use
> public IP addresses yet decline to provide services for clients outside that
> ISP, with responses like this:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 2800
> ;; QUESTION SECTION:
> ;freedesktop.org.   IN  A
>
> (note it’s not an NXDOMAIN)
>
> The second IP address is more honest and sets status: REFUSED.
>
> This situation results in the following behavior: if I query some domain, it
> always fails for the first time then works afterwards.
>
> $ resolvectl query google.com.uy
> google.com.uy: resolve call failed: 'google.com.uy' does not have any RR of
> the requested type
>
> $ resolvectl query google.com.uy
> google.com.uy: 172.217.169.163 -- link: usb0
>
> -- Information acquired via protocol DNS in 5.8ms.
> -- Data is authenticated: no
>
> Did I misconfigure something? Did I misread resolved.conf(5) which states “Use
> the construct "~." to use the system DNS server defined with DNS= preferably
> for all domains”? Is there a bug?
>
> --
> TIA
> Roman.
>
>
> ___
> 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] Journal message timestamps

[Kevin P. Fleming]

On Tue, Sep 8, 2020 at 7:12 AM Reindl Harald  wrote:

> your playground is in
> /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf
>
> and yes that is important so that you don#t have to redo your changes
> after each and every update and way better than cloning the whole
> unit-file in /etc/systemd/system/ so that reasonable upstream changes
> get applied in teh future
>
> -
>
> /etc/systemd/system/fake-hwclock.service.d/myoverrides.conf:
>
> [Unit]
> Before=systemd-journald.service

... and this is most easily done by using 'systemctl edit
fake-hwclock.service', which will create the file in the proper
location so you don't have to (and will handily cause a daemon reload
as well).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: User/Group overrides in a templated service triggered via timer

[Kevin P. Fleming]

On Mon, Sep 7, 2020 at 11:58 AM Lennart Poettering
 wrote:
> Not sure I can parse this. Both timers and services are units in
> systemd. You can enable timer units, and you can enable service units,
> it all depends on what you put in their [Install] section. Sometimes
> it makes sense to add an [Install] section to one, sometimes to the
> other, sometimes to both, dependning on what the triggers should be
> that you want to use. Pretty often it might make sense to include just
> an Also=foobar.timer in the [Install] section of foobar.service, which
> then means that if the service is enabled, foobar.timer is enabled
> implicitly.

Hindsight being 20/20, it would probably have made more sense to users
if the command was 'systemctl install' since that would match the
section name in the unit file. It's a bit late for that now :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Journal message timestamps

[Kevin P. Fleming]

On Mon, Sep 7, 2020 at 4:41 AM Ulrich Windl
 wrote:
> I can't remember, but very recently I read that you can add an RTC to
> raspberries via GPIO. Ah, I think I read it in the SLES15 SP2 deployment
> guide.

It's typically done via I2C; there are quite inexpensive DS-1307
modules that plug onto the 40-pn header for example.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: User/Group overrides in a templated service triggered via timer

[Kevin P. Fleming]

On Mon, Sep 7, 2020 at 4:22 AM Reindl Harald  wrote:
> a timer is the same trigger as "enable" and get startet as part of the
> boot process
>
> * letsencrypt.timer
> * letsencrypt.service
>
> letsencrypt.service don't even have a [Install] section and can't be
> enabled at all

'disabling' a service so that it won't be run, even by a timer, can be
done with 'systemctl mask', although if the unit file is located in
/etc/systemd/system that may not be possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] non-existent unit instances

[Kevin P. Fleming]

On Sat, Sep 5, 2020 at 9:50 AM Michael Chapman  wrote:
> Since the instance name for this unit is used to derive a configuration
> filename, a simple solution here would be to use:
>
> ConditionPathExists=/etc/openvpn/client/%i.conf
>
> in the unit. Or, if you want the start job to fail when given a bad
> instance name:
>
> AssertPathExists=/etc/openvpn/client/%i.conf

Thanks for this tip, this is very useful! I have a number of service
units which launch scripts and those scripts will fail if their
configuration files are not present; it will be handy to have the
start job itself fail in this situation.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] non-existent unit instances

[Kevin P. Fleming]

It's a general issue with templated unit files; I've had this happen
as well, and could not figure out why the service had failed to start.
It was because I had mistyped the instance name. As best I can tell
systemd doesn't have any mechanism to restrict the instance names
which can be used for a specific unit file, so it can't know that the
requested instance cannot be started.

On Sat, Sep 5, 2020 at 2:46 AM Richard Hector  wrote:
>
> Hi all,
>
> Quoting from another thread:
>
> On 5/09/20 4:36 am, Lennart Poettering wrote:
> > Unit instances can be activated on-the-fly without further prepartion
> > or regsitration of the instance string or so. it's sufficient if the
> > template unit exists.
>
> Is that preventable?
>
> I have some instance names that are easily typoed. When I start one with
> the wrong name, it sticks around trying to restart for ever - or at
> least till I notice it or reboot - where I'm much rather get an error
> message and stop.
>
> For reference, this is with the openvpn-client@ (and maybe
> openvpn-server@) units in Debian buster. Some of the content was
> modified/overwritten by me, so it could well be a bug introduced by me.
>
> The typos are because my instances are based on hostname, which can
> contain '-' but not '_'. Instance names can apparently not contain '-',
> so I have to use '_' instead, but my muscle memory for my hostnames is
> strong.
>
> I don't know if this is a result of the way the units are written, or an
> inherent issue with systemd.
>
> Cheers,
> Richard
> ___
> 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] Journal message timestamps

[Kevin P. Fleming]

I've run into similar issues and resorted to adding battery-backed
RTCs to my RPis in order to ensure that the kernel's clock would be
set to something 'reasonable' very early in the boot process (although
it's still not ideal since the RTC drivers are loaded as modules so
the kernel's code for doing this can't read them... it has to be done
in userspace very early).

Given the low cost of RTC chips and supercaps to power them, the fact
that RPis still don't include a hardware RTC in their fourth
generation is a major failing. In spite of that the boards are quite
useful.

On Fri, Sep 4, 2020 at 6:00 PM Lennart Poettering
 wrote:
>
> On Fr, 04.09.20 22:02, Dave Howorth (syst...@howorth.org.uk) wrote:
>
> > > (btw, systemd-timesyncd does what fake-hwclock does automatically, and
> > > also does SNTP. it should be fine for most usecases, no need to resort
> > > to fake-hwclock)
> > >
> > > Lennart
> >
> > This is a serious problem for anybody running a raspberry pi (i.e.
> > many, many thousands of people.) I suggest buying one for yourself and
> > actually experiencing the issues to understand what the problem is and
> > why people would like to see a solution.
>
> I understand the problem, and would be happy to review/merge a patch
> that addresses this cleanly.
>
> I had some raspberry pis, but I gave them away, since I never found a
> use for them.
>
> > I'll send you the dollars if that's really a problem.
>
> It's not a money problem. Raspberry pis are simply not at the center
> of my personal attention. But there are many other engineers in this
> world, maybe you can find one that shares your priorities on this and
> he will fix it for you. I am not going to be that, but at least I can
> offer to review the patches and merge them if they are good.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> 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] User/Group overrides in a templated service triggered via timer

[Kevin P. Fleming]

Ahh, you're right. I do not 'enable' my timer-activated service units,
since 'enable' just processes the WantedBy/similar specifications to
create symlinks.

On Mon, Aug 31, 2020 at 4:50 PM Konstantin Ryabitsev
 wrote:
>
> On Mon, Aug 31, 2020 at 04:49:32PM -0400, Kevin P. Fleming wrote:
> > Yes, to get the instance-named symlink created.
>
> Wouldn't that execute the service on boot, or does that not apply to
> oneshot items?
>
> -K
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] User/Group overrides in a templated service triggered via timer

[Kevin P. Fleming]

Yes, to get the instance-named symlink created.

On Mon, Aug 31, 2020 at 4:36 PM Konstantin Ryabitsev
 wrote:
>
> On Mon, Aug 31, 2020 at 04:20:13PM -0400, Kevin P. Fleming wrote:
> > Did you also create an instance of the timer with the same instance
> > suffix? I've got a configuration working like that and it works fine.
> > If you don't want to do that, you can explicitly configure the name of
> > the service to be triggered (in the timer unit) instead of relying on
> > the timer/service names matching.
>
> Ah, hmm... So, I enable and start grok-fsck@foo.timer -- do I need to
> enable (but not start) grok-fsck@foo.service as well?
>
> -K
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] User/Group overrides in a templated service triggered via timer

[Kevin P. Fleming]

Did you also create an instance of the timer with the same instance
suffix? I've got a configuration working like that and it works fine.
If you don't want to do that, you can explicitly configure the name of
the service to be triggered (in the timer unit) instead of relying on
the timer/service names matching.

On Mon, Aug 31, 2020 at 2:19 PM Konstantin Ryabitsev
 wrote:
>
> Hi, all:
>
> I have the following templated service definition:
>
> --- grok-fsck@.service ---
> [Unit]
> Description=Grok-fsck service for %I
> Documentation=https://github.com/mricon/grokmirror
>
> [Service]
> Type=oneshot
> Environment="EXTRA_FSCK_OPTS="
> EnvironmentFile=-/etc/sysconfig/grokmirror.default
> EnvironmentFile=-/etc/sysconfig/grokmirror.%i
> ExecStart=/usr/bin/grok-fsck -c /etc/grokmirror/%i.conf ${EXTRA_FSCK_OPTS}
> IOSchedulingClass=idle
> CPUSchedulingPolicy=idle
> User=mirror
> Group=mirror
> --- end ---
>
> It has a corresponding timer:
>
> --- grok-fsck@.timer ---
> [Unit]
> Description=Grok-fsck timer for %I
> Documentation=https://github.com/mricon/grokmirror
>
> [Timer]
> OnCalendar=Sat 04:00
>
> [Install]
> WantedBy=timers.target
> --- end ---
>
> I need to be able to modify User/Group for the process, to allow running
> grok-fsck as a different user. For a regular service, I would create a
> /etc/systemd/system/grok-fsck@[foo].d/10-runas.conf:
>
> --- 10-runas.conf ---
> [Service]
> User=someotheruser
> Group=someothergroup
> --- end ---
>
> However, it doesn't appear to be working for a service triggered via a
> timer -- the process still runs as mirror/mirror.
>
> What's the best way to make this work properly?
>
> TIA,
> -K
>
> ___
> 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] Accpetance of Environment Variables in Attributes

[Kevin P. Fleming]

On Fri, Jun 26, 2020 at 3:39 AM Ede Wolf  wrote:
>
> > I do this today using a drop-in, because environment variables can be
> > set there as well. It works very well, exactly as you describe. There
> > is a template service unit file, and a drop-in directory for each
> > instance which contains a file that sets the environment variables and
> > also provides values for keys in the [Unit] and [Service] sections.
>
> Would you mind to explain, what is the benefit of this approach compared
> to having a dedicated unit file for each service?

When you have multiple instances of a service which differ only
slightly (for example, the launch directory and service name), it's
very convenient to have all of the common settings in a single file
and only provide the *differences* in drop-in files. Systemd's
handling of templates and instances makes this very easy to do. It's
not necessary though, you can certainly duplicate all of the
configuration in the unit files, including setting necessary
environment variables.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Kevin P. Fleming]

On Thu, Jun 25, 2020 at 4:04 PM Ede Wolf  wrote:
> This way I would only have to take care of _one_ external file to get
> another instance of service foo up and running. Copy the file, change
> the few options for the unit as well as for the service in ONE place,
> startup the template. Ultra elegant and fast, especially when dealing
> with 10+ instances of the same service, that only have little variation
> like the running user, limits and one or two different service arguments.

I do this today using a drop-in, because environment variables can be
set there as well. It works very well, exactly as you describe. There
is a template service unit file, and a drop-in directory for each
instance which contains a file that sets the environment variables and
also provides values for keys in the [Unit] and [Service] sections.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Kevin P. Fleming]

Normally you'd set instance-specific variables using an override file
for the unit. You could easily put just 'User' and 'LimitMEMLOCK' in
the override file and leave the rest of the service settings in the
main unit file, with no need for an environment variable file at all.

On Thu, Jun 25, 2020 at 7:24 AM Ede Wolf  wrote:
>
> So I have an environmentfile containing two variable definitions:
>
> RUNASUSER=nobody
> MEM=4294967296
>
> And my service section reads:
>
> [Service]
> EnvironmentFile=/path/myfile
> User=$RUNASUSER
> LimitMEMLOCK=$MEM
>
> This service failes to startup, as I cannot seem to being able to  use a
> variable for the User attribute, but I may very well for LimitMEMLOCK.
>
> Error:
>
> Failed to determine user credentials: No such process
>
>
> And if specifying instead:
>
> [Service]
> EnvironmentFile=/path/myfile
> User=nobody
> LimitMEMLOCK=$MEM
>
> Everything does work. And I am wondering, why? And moreover, is there
> any source of documentation, that lists or even explains, what
> attributes may have a variable as an argument and what do not?
>
> As for instances/template units it would be really helpful to being able
> to set the running user in the configuration/environment file. Or at
> least have a knowledge of those settings, that do not allow this, for
> what reason ever. Especially when talking about directory settings.
>
> ___
> 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] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Kevin P. Fleming]

Do you have a udev 'persistent network device name' rules file in
/etc/udev/rules.d? Many distributions install such a rules file by
default, and this renames the interfaces to 'standard' names.

On Fri, May 22, 2020 at 3:47 AM Ede Wolf  wrote:
>
> Hello,
>
> I am trying to enable temporary and/or stable addresses for a link and
> am most likely running into troubles with the device naming. However, I
> do not change any network name myself, neither in udev nor as part or a
> link file, it's just the standard system settings (from Arch, in case
> that matters).
>
> my sysctl.conf (both ens3 and eth0 refer to the same interface):
>
>
> net.ipv6.conf.ens3.addr_gen_mode = 2
> net.ipv6.conf.ens3.use_tempaddr = 2
>
> net.ipv6.conf.eth0.addr_gen_mode = 2
> net.ipv6.conf.eth0.use_tempaddr = 2
>
>
> And the logs read:
>
> journalctl -b0 | grep -E 'sysctl|ens3|eth0'
> 08:56:46 systemd[263]: systemd-sysctl.service: Executing:
> /usr/lib/systemd/systemd-sysctl
> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
> 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory
> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to
> 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory
> 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0
> 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead
> -> plugged
> 08:56:47 systemd[1]:
> sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed
> dead -> plugged
> 08:56:51 systemd-networkd[459]: ens3: Interface name change detected,
> ens3 has been renamed to eth0.
> 08:56:51 systemd-networkd[459]: eth0: Interface name change detected,
> eth0 has been renamed to ens3.
> 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled
> 08:56:51 systemd-networkd[459]: ens3: Link UP
> 08:56:51 systemd-networkd[459]: ens3: Gained carrier
> ...
>
>
> As it appears to me, the eth0 settings from sysctl.conf have been
> accepted - at least no errors are logged in this regard -, but are lost,
> because the interface got renamed afterwards. The ens3 interface was not
> yet known at time of invoking systemd-sysctl, and therefore we get the
> errors. That in turn means, the settings are not being applied.
>
> To make things worse, in sysctl.conf I've additionally set:
>
> net.ipv6.conf.default.stable_secret=
> net.ipv6.conf.default.addr_gen_mode=2
> net.ipv6.conf.all.addr_gen_mode=2
>
>
> Which results in all IP address having a stable privacy scope link,
> _execpt_ of course ens3. The one that would be by far most important.
>
> What am I missing here? And insight is highly appreciated
>
> Thanks
>
> Ede
> ___
> 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] IPv6 dhcp-acquired prefix delegation?

[Kevin P. Fleming]

You have to accept RAs from upstream, unless you have a static route
to the ISP's gateway. DHCPv6 does not provide routing information,
only end-node addressing information, so with RAs ignored you won't
have a default route out of your network.

This is probably the largest, and most surprising, difference between
DHCPv4 and DHCPv6.

On Sat, May 16, 2020 at 8:40 PM John Ioannidis  wrote:
>
> I am running systemd v241, the one that comes with debian-10.
>
> Is the following scenario possible natively (that is, without using a 
> standalone dhcpv6 client)?
>
> My residential ISP will normally hand me a /64, but will give me a /56 if I 
> ask for it. While technically not a statically-allocated prefix, it changes 
> very rarely: I had had the same prefix for over three years until I started 
> experimenting with systemd-networkd and killed my old lease files.
> I have several local vlans, and I want to give a different /64 to each one of 
> them, but if the prefix I get from upstream changes, I want them to 
> automatically renumber.
> I'm perfectly happy relying on SLAAC for the local vlans, but I'm not against 
> having to also run a dhcpv6 server to hand out addresses and things.
>
> My previous solution, using ifupdown instead of systemd was this:
>
> dhcpv6 client with -P --prefix-len-hint 56, which gets the /56 and the 
> default route.
> A script in /etc/dhcp/dhclient-exit-hooks.d/ that builds an /etc/radvd.conf 
> file with bits 56-63 appropriately numbered, and then restarts radvd.
>
> I have been totally unable to reproduce this behavior with pure networkd; in 
> fact, I cannot even get a dhcpv6 session going. I do not want to rely on RAs 
> from upstream, just DHCPv6. Here is a minimal .network file for the external 
> interface ("ethwan")
>
> [Match]
> Name=ethwan
>
> [Network]
> DHCP=yes
> IPForward=yes
> IPMasquerade=no
> IPv6PrivacyExtensions=no
> IPv6AcceptRA=no
>
> [DHCP]
> UseDNS=no
> UseNTP=yes
> UseRoutes=yes
>
> ___
> 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 modify systemd so that the NTP function is disabled when systemd is first started?

[Kevin P. Fleming]

What does 'update the system' mean for you?

On Fri, Apr 17, 2020 at 6:10 AM www  wrote:
>
>
> I mean that this configuration can be preserved, even after I update the 
> system, this function can be saved.
>
> thanks，
> Byron
>
>
>
>
> At 2020-04-17 18:06:15, "Kevin P. Fleming"  wrote:
> >Both of those changes will stop the service from being started, even
> >when the system is rebooted. You don't need to run these commands
> >every time, running them one time will change the system configuration
> >and the service will no longer be started.
> >
> >On Fri, Apr 17, 2020 at 2:52 AM www  wrote:
> >>
> >> hi Kevin ,
> >>
> >> Thank you very much for you help. But how can I save this way of closing 
> >> time synchronization by command after system boot up? After I update the 
> >> system, the first time I start it, time synchronization is still enabled 
> >> by default. It's not appropriate if I close it alone every time. So when I 
> >> need it start every time, this function is off.
> >>
> >>
> >> thanks,
> >> Byron
> >>
> >>
> >>
> >>
> >>
> >> At 2020-04-16 18:28:30, "Kevin P. Fleming"  wrote:
> >> >There is no need to modify systemd.
> >> >
> >> >$ systemctl disable systemd-timesyncd
> >> >
> >> >That command will stop the systemd-timesyncd service from being
> >> >started. It may also be necessary to mask it:
> >> >
> >> >$ systemctl mask systemd-timesyncd
> >> >
> >> >On Thu, Apr 16, 2020 at 6:22 AM www  wrote:
> >> >>
> >> >> Dear all，
> >> >>
> >> >> I want to ask a question，How to modify systemd so that the NTP function 
> >> >> is disabled when systemd is first started?
> >> >>
> >> >>  The default state of systend is to synchronize time from NTP. We can 
> >> >> use timedatectl command to disable NTP synchronize time. But if I flash 
> >> >> the system, the NTP  synchronize time function will auto enable.  so I 
> >> >> want modify the systemd and disable NTP synchronize time in default 
> >> >> state.
> >> >>
> >> >> thanks,
> >> >> Byron
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ___
> >> >> 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 modify systemd so that the NTP function is disabled when systemd is first started?

[Kevin P. Fleming]

Both of those changes will stop the service from being started, even
when the system is rebooted. You don't need to run these commands
every time, running them one time will change the system configuration
and the service will no longer be started.

On Fri, Apr 17, 2020 at 2:52 AM www  wrote:
>
> hi Kevin ,
>
> Thank you very much for you help. But how can I save this way of closing time 
> synchronization by command after system boot up? After I update the system, 
> the first time I start it, time synchronization is still enabled by default. 
> It's not appropriate if I close it alone every time. So when I need it start 
> every time, this function is off.
>
>
> thanks,
> Byron
>
>
>
>
>
> At 2020-04-16 18:28:30, "Kevin P. Fleming"  wrote:
> >There is no need to modify systemd.
> >
> >$ systemctl disable systemd-timesyncd
> >
> >That command will stop the systemd-timesyncd service from being
> >started. It may also be necessary to mask it:
> >
> >$ systemctl mask systemd-timesyncd
> >
> >On Thu, Apr 16, 2020 at 6:22 AM www  wrote:
> >>
> >> Dear all，
> >>
> >> I want to ask a question，How to modify systemd so that the NTP function is 
> >> disabled when systemd is first started?
> >>
> >>  The default state of systend is to synchronize time from NTP. We can use 
> >> timedatectl command to disable NTP synchronize time. But if I flash the 
> >> system, the NTP  synchronize time function will auto enable.  so I want 
> >> modify the systemd and disable NTP synchronize time in default state.
> >>
> >> thanks,
> >> Byron
> >>
> >>
> >>
> >>
> >> ___
> >> 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] "known-good" DNS servers for use with resolved and DNSSEC

[Kevin P. Fleming]

I have a working-well configuration using PowerDNS Recursive Resolver
(running locally in my network, not provided by my ISP or anyone
upstream).

On Thu, Apr 16, 2020 at 12:46 PM Fabian Bernhard Pack
 wrote:
>
> Hi,
>
> I've been slowly integrating systemd-resolved more and more into my
> setups, but I had always encountered stability issues whenever the
> upstream DNS resolver has some kind of DNSSEC support. Setting
> DNSSEC=true would result in periods of no name resolution at all,
> leaving it at the default `allow-downgrade` would have it work most of
> the time, though switching DNSSEC support on and off periodically, and
> sometimes not being able to resolve a query that should have resolved.
>
> The troubles seem to occur whenever the upstream DNS cannot resolve a
> query, but for legitimate reasons. For example, the resolver is a
> recursive one and the authoritative nameservers for the queried zones
> return SERVFAIL. The resolver passes that SERVFAIL down to systemd-
> resolved, which seems to take it as a sign that the upstream does not
> support DNSSEC, and turns the feature off. If DNSSEC=true, the resolver
> is then blacklisted for the duration of the grace period, if
> DNSSEC=allow-downgrade the feature set is reduced.
>
> Looking through the bug reports, I got the impression that the DNSSEC
> support of systemd-resolved (or at least it's DNSSEC detection support)
> was simply in a bad shape and needed a rewrite, which was what lead me
> to disable it.
> But now Fedora has brought up the proposal to switch to systemd-
> resolved by default, though with DNSSEC disabled by default. In that
> discussion Lennart Poettering mentioned that the reasons for the
> instabilities observed with DNSSEC support turned on are to be found in
> the erratic behaviour of upstream DNS resolvers, and the efforts of
> systemd-resolved to detect this.
> (See
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AFHNUEHKC5KJVGBGSJBH2BMESUAGDF4H/
> )
>
> Please don't take this the wrong way, but I am now wondering what the
> correct behaviour for an upstream DNS should be. I had tried unbound
> and dnsmasq in the past (of course with DNSSEC enabled and passing down
> the relevant RRs to resolved), and with both I encountered the
> instabilities.
> If you have a setup with systemd-resolved and DNSSEC enabled, can you
> tell me what the upstream DNS is running? I would like to know a
> "known-good" DNS server implementation, to see what it is doing
> different than my unbound/dnsmasq.
>
> Kind regards,
> Fabian Pack
>
>
> ___
> 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 modify systemd so that the NTP function is disabled when systemd is first started?

[Kevin P. Fleming]

There is no need to modify systemd.

$ systemctl disable systemd-timesyncd

That command will stop the systemd-timesyncd service from being
started. It may also be necessary to mask it:

$ systemctl mask systemd-timesyncd

On Thu, Apr 16, 2020 at 6:22 AM www  wrote:
>
> Dear all，
>
> I want to ask a question，How to modify systemd so that the NTP function is 
> disabled when systemd is first started?
>
>  The default state of systend is to synchronize time from NTP. We can use 
> timedatectl command to disable NTP synchronize time. But if I flash the 
> system, the NTP  synchronize time function will auto enable.  so I want 
> modify the systemd and disable NTP synchronize time in default state.
>
> thanks,
> Byron
>
>
>
>
> ___
> 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] Systemd-resolved: --set-domains limited to 32 domains

[Kevin P. Fleming]

'git grep 32' would be more effective :-)

On Wed, Apr 15, 2020 at 4:50 PM Andy Pieters  wrote:
>
> On Wed, 15 Apr 2020 at 21:46, Tarun Chinmai Sekar  wrote:
> >
> > Hello Lennart,
> > Thank you for the quick response. I'd love to submit a PR to increase the 
> > limit. Can you please point me to right parts of the code?
>
> How about ...
>
> git clone ...
> cd systemd
> grep 32 -R .
>
>
> ?
>
> Sorry for the facetious answer :p
> ___
> 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] networkd: IPv6 prefix delegation not updated when prefix changes

[Kevin P. Fleming]

Yes, I agree with you there.

On the other part I imagine there may be some way to trigger a service
to be run when a prefix on a link is being taken out of service.

On Mon, Apr 13, 2020 at 11:51 AM Tobias Brink  wrote:
>
> "Kevin P. Fleming"  writes:
>
> > This is a bit tricky, since RAs and prefix delegation are not really
> > related. [...] What it can't do is trigger a new prefix delegation
> > request as a result, because they are not really related. [...]
> >
> > What you're experiencing here is a delegation which has expired
> > earlier than the DHCPv6 server claimed that it would expire, which is
> > really unfriendly.
>
> OK, so that part might not be fixable or needs some specific workaround
> for my situation. Nevertheless, as soon as networkd sends a Renew for
> the delegated prefix and it gets a NoBinding reponse, it should request a
> new delegated prefix, right? That didn't work for me either, see quoted parts
> below.
>
> > On Mon, Apr 13, 2020 at 11:18 AM Tobias Brink  
> > wrote:
> >>
> >> 4) Still a bit later, networkd wants to renew the 2001:1:0:1::/64 prefix
> >>of br0 and sends a DHCPv6 Renew. The ISP-provided router responds
> >>with "NoBindig", status message "prefix mismatch" (changing later to
> >>"iapd not found"), which is of course correct. networkd, though, just
> >>keeps retrying to renew that prefix without success.
> >>
> >> [...]
> >>
> >> At the very least, in step (4), I would have thought that after being
> >> unsuccessful in renewing the prefix, networkd would try to obtain a new
> >> one. RFC 8415 (Sec. 18.2.10.1) seems to agree as far as I understand:
> >> Upon a NoBinding response for any delegated prefix, the client should
> >> send a Request.
>
> Thanks,
>
> Tobias
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: IPv6 prefix delegation not updated when prefix changes

[Kevin P. Fleming]

This is a bit tricky, since RAs and prefix delegation are not really
related. What you have described is proper behavior on the 'upstream'
link side; when networkd sees the RA with the new prefix, and the
lifetime of the old prefix set to zero, it properly adjusts that link
to use the new prefix.

What it can't do is trigger a new prefix delegation request as a
result, because they are not really related. Commonly, the link used
between the router which asks for the delegation and the router which
provides it uses a prefix which is totally unrelated to the delegated
prefix, and so changes to the prefix on that inter-router link don't
affect the delegation at all.

What you're experiencing here is a delegation which has expired
earlier than the DHCPv6 server claimed that it would expire, which is
really unfriendly.

On Mon, Apr 13, 2020 at 11:18 AM Tobias Brink  wrote:
>
> Hello systemd devs and users,
>
> my internet connection is established by a router provided by my ISP (a
> Fritz Box to be precise). It can hand out delegated IPv6 prefixes via
> DHCPv6. I use a Linux box in between this router and my internal network
> to provide additional firewalling, OpenVPN, etc. For this, I request an
> IPv6 prefix for the internal network using networkd. This works. But the
> provider (like most non-business offerings) resets the public IPv4
> address and IPv6 prefix from time to time. The prefix delegation on my
> Linux box is not updated at this point and the old delegated prefix
> expires. Only "networkctl reconfigure" on the external interface leads
> to a new prefix delegation being obtained. Routes for the old prefixes,
> though, remain indefinitely, potentially causing trouble.
>
> I do believe this to be a problem with networkd, but I'm new to IPv6 and
> wanted to ask here first if there's a problem with my configuration or
> if the ISP-provided router is maybe buggy instead. If I should instead
> open an issue on GitHub or if more information is needed, please tell
> me.
>
> All details below:
>
> Setup
> =
>
> I use the current Debian stable (buster) with systemd from backports
> (systemd --version: "systemd 244 (244.3-1~bpo10+1)"). I also quickly
> tried compiling and running networkd from git master, but the issue
> seems to remain unfixed.
>
> Configuration:
>
> #/etc/systemd/network/10-enp3s0.network <- the "external" interface
>
> [Match]
> Name=enp3s0
>
> [Network]
> Address=
> Gateway=
> Address=fdxx:::::1/64
> IPv6AcceptRA=yes
> DHCP=ipv6
> IPv6PrivacyExtensions=true
>
> [DHCPv6]
> # Note: usually, the ISP router is configured to only set the "Other
> # Configuration" flag. I also tried changing it to set the "Managed"
> # flag in router advertisements, but with the setting below, there
> # is no difference in the behavior of networkd.
> ForceDHCPv6PDOtherInformation=yes
>
>
> #/etc/systemd/network/20-br0.network <- the "internal" interface
>
> [Match]
> Name=br0
>
> [Network]
> Address=
> Address=fdxx:::::1/64
> IPv6PrefixDelegation=yes
>
> [IPv6PrefixDelegation]
> Managed=yes
> OtherInformation=yes
> RouterLifetimeSec=7200
> EmitDNS=yes
> DNS=fdxx:::::1
> DNSLifetimeSec=7200
>
> [IPv6Prefix]
> Prefix=fdxx:::::/64
> ValidLifetimeSec=7200
> PreferredLifetimeSec=3600
>
>
> The issue
> =
>
> This is an example observed with the help of tcpdump and log files. I
> still have this data if more details are needed.
>
> For the sake of the example, let's say the public IPv6 prefix was
> 2001:1:0:0::/56 before resetting the internet connection and
> 2001:2:0:0::/56 after.
>
> 0) enps0 has a prefix of 2001:1:0:0::/64 (obtained via router
>advertisement); br0 a prefix 2001:1:0:1::/64 (obtained via DHCPv6
>prefix delegation).
>
> 1) Internet connection is reset. The ISP-provided router sends a router
>advertisement with a new IPv6 prefix 2001:2:0:0::/64 with a preferred
>lifetime of 3600 and the old prefix 2001:1:0:0::/64 with a preferred
>lifetime of 0. The "Other Configuration" flag is set.
>
> 2) networkd updates enp3s0 with this prefix. No DHCPv6 traffic is
>triggered. The configuration of br0 remains unchanged. The old prefix
>is no longer accepted by the ISP and IPv6 connectivity is lost for
>the internal network.
>
> 3) A while later, the ISP-provided router sends a new router
>advertisement, this time only containing the new IPv6 prefix
>2001:2:0:0::/64. This triggers no changes in networkd.
>
> 4) Still a bit later, networkd wants to renew the 2001:1:0:1::/64 prefix
>of br0 and sends a DHCPv6 Renew. The ISP-provided router responds
>with "NoBindig", status message "prefix mismatch" (changing later to
>"iapd not found"), which is of course correct. networkd, though, just
>keeps retrying to renew that prefix without success.
>
> At that point I can use "networkctl reconfigure enp3s0". This (almost)
> fixes it and br0 obtains (for example) the new, valid prefix
> 2001:2:0:1::/64. 

Re: [systemd-devel] your are happier but without become static some service I can't loggin by console-getty et getty@tty1 services

[Kevin P. Fleming]

Dorian: Please find a French-language support forum or mailing list
for Fedora Linux. They'll be glad to help you, and will be able to
address your questions in the Fedora system.

On Tue, Apr 7, 2020 at 6:08 PM Dave Howorth  wrote:
>
> I'm not sure why Lennart hasn't stepped in to moderate yet, but this
> discussion is going in my bit bucket.
>
> On Tue, 7 Apr 2020 22:03:25 +
> Dorian ROSSE  wrote:
> > I explain again the problem juice
> >
> > I can't use my monitor foe edit script
> >
> > Because console-getty et getty@tty1 service are disabled,
> >
> > I can start but I want both service become static,
> >
> > How to become both service as static ?
> >
> > Envoyé d’Outlook Mobile
> > 
> > From: Dorian ROSSE
> > Sent: Tuesday, April 7, 2020 7:47:53 PM
> > To: systemd-devel@lists.freedesktop.org
> >  Subject: your are happier but
> > without become static some service I can't loggin by console-getty et
> > getty@tty1 services
> >
> > Hello,
> >
> >
> > your are happier but without become static some service I can't
> > loggin by console-getty et getty@tty1 services on my monitor...
> >
> > I have tried too ssh access but ssh mailing list has never answer my
> > e-mail...
> >
> > thank you in advance to help me become static some services,
> >
> > Regards.
> >
> >
> > Dorian ROSSE.
> ___
> 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] Cannot find a way to get time read from RTC during boot

[Kevin P. Fleming]

The simple service unit I posted later in the thread (which invokes
hwclock) works great for me.

On Tue, Mar 31, 2020 at 1:29 PM Michał Zegan  wrote:
>
> I have used the embedded term unfortunately, but it seems to affect at
> least some devices like raspberry pi, odroid c2, like sbc's.
>
> W dniu 31.03.2020 o 17:57, Lennart Poettering pisze:
> > On Di, 31.03.20 17:39, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> >
> >> Seems like rtc drivers as module is quite often a thing for embedded.
> >> But not sure where this should be solved, maybe at initramfs? If one is
> >> unwilling to build all rtc drivers into the kernel (the case of generic
> >> kernels where you would have to build all of them in)...
> >
> > Is that realistic? embedded devices and fully generic kernels?
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] netdev templates and location of network units

[Kevin P. Fleming]

Input files for systemd-networkd are not systemd unit files, so
there's a good chance that the rules for finding and processing them
are much simpler. That would explain why template/instance files don't
work.

The manpage for systemd.network does indicate that files will be
loaded from /usr/local/lib/systemd/network though, so if they aren't
being picked up that's odd.

https://www.freedesktop.org/software/systemd/man/systemd.network.html

On Mon, Mar 23, 2020 at 6:51 AM Christian Schneider
 wrote:
>
> Hi all,
> for an embedded device with Linux and systemd boot, we wanted to deploy
> custom network and netdev units.
> We tried placing them in /usr/local/lib/systemd/network, next to service
> files for custom services in /usr/local/lib/systemd/system. The network
> units aren't picked up by systemd, the custom service files are, though.
> Since this was a bit surprising, I want to ask, what is the rationale
> behind this, and what would be the recommended location of the
> network/netdev files? Right now we placed them in /etc/systemd/network
>
> Furthermore, since we make heavy use of vlan, I tried to create a
> template netdev file where the instance goes in as vlan id, but when I
> tried to reference instance of the template in the network file, I got
> syntax errors. Is there a rational behind this or is it just not
> implemented to be use templates for netdev?
>
> BR, Christian
>
> ___
> 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] Cannot find a way to get time read from RTC during boot

[Kevin P. Fleming]

Indeed, I landed there later after my reply. I'm disappointed that it
was never resolved, but I did add a service unit which works
perfectly.

-

[Unit]
Description=Set system clock from hardware clock
After=systemd-modules-load.service

[Service]
Type=oneshot
ExecStart=/sbin/hwclock --hctosys --utc

[Install]
WantedBy=basic.target

On Thu, Mar 12, 2020 at 7:26 PM Dave Howorth  wrote:
>
> On Thu, 12 Mar 2020 17:35:16 -0400
> "Kevin P. Fleming"  wrote:
> > Thanks, I agree. I could some up with something which ran timedatectl
> > to set the system time from the RTC, but the hwclock tool is already
> > there for that purpose.
> >
> > I'll need to investigate why this script exits without making any
> > changes when systemd is running; either the authors expected some part
> > of systemd to read the RTC, or they expect some other service/tool to
> > do it.
> >
> > On Thu, Mar 12, 2020 at 2:02 PM Mike Gilbert 
> > wrote:
> > >
> > > On Thu, Mar 12, 2020 at 7:13 AM Kevin P. Fleming 
> > > wrote:
> > > > Prior to systemd, with the 'hwclock' package installed, a udev
> > > > rule would trigger reading of the RTC and setting the system
> > > > clock when /dev/rtc0 appeared. With systemd running, the script
> > > > run by that udev rule is suppressed, it doesn't do anything.
> > > >
> > > > With a system using solely systemd-provided services, what's the
> > > > proper mechanism to get the time read from an RTC whose driver is
> > > > loaded by systemd-modules-load.service?
> > >
> > > Your use case is likely not covered by "systemd-provided" services.
> > >
> > > I think your best bet would be to "un-supress" that hwclock udev
> > > rule.
>
> I'm not sure but you might be interested to read
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203
> ___
> 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] Cannot find a way to get time read from RTC during boot

[Kevin P. Fleming]

Thanks, I agree. I could some up with something which ran timedatectl
to set the system time from the RTC, but the hwclock tool is already
there for that purpose.

I'll need to investigate why this script exits without making any
changes when systemd is running; either the authors expected some part
of systemd to read the RTC, or they expect some other service/tool to
do it.

On Thu, Mar 12, 2020 at 2:02 PM Mike Gilbert  wrote:
>
> On Thu, Mar 12, 2020 at 7:13 AM Kevin P. Fleming  wrote:
> > Prior to systemd, with the 'hwclock' package installed, a udev rule
> > would trigger reading of the RTC and setting the system clock when
> > /dev/rtc0 appeared. With systemd running, the script run by that udev
> > rule is suppressed, it doesn't do anything.
> >
> > With a system using solely systemd-provided services, what's the
> > proper mechanism to get the time read from an RTC whose driver is
> > loaded by systemd-modules-load.service?
>
> Your use case is likely not covered by "systemd-provided" services.
>
> I think your best bet would be to "un-supress" that hwclock udev rule.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Cannot find a way to get time read from RTC during boot

[Kevin P. Fleming]

I've got some Debian Buster systems (so using the Debian systemd
package 241-7), which have battery-backed RTCs. However the driver for
these RTCs is loaded as a module, not built into the kernel. As a
result the kernel's feature of reading the RTC to set the system clock
is not available.

Prior to systemd, with the 'hwclock' package installed, a udev rule
would trigger reading of the RTC and setting the system clock when
/dev/rtc0 appeared. With systemd running, the script run by that udev
rule is suppressed, it doesn't do anything.

I have systemd-timesyncd started at boot as well and syncing time with
an NTP server; that works fine when the system clock is set to
something reasonably close to the actual time. If it's not, then
timesyncd can't adjust the time because it's too far off (and in
addition I have the issue reported on GitHub where systemd-resolved
can't resolve NTP server names due to DNSSEC failing because the clock
is too far off...) The file that systemd-timesyncd stores for use on
reboot helps a little, but if the system is shut off for a period of
time (an hour or more) then the time at startup is quite far off from
reality, which is why I have an RTC :)

With a system using solely systemd-provided services, what's the
proper mechanism to get the time read from an RTC whose driver is
loaded by systemd-modules-load.service?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel