[systemd-devel] DynamicUser=yes leads to "Too many levels of symbolic links" for /etc/.pwd.lock

[Muggeridge, Matt]

Hi,

I'm using systemd-v254.

My rdisc service fails to start when "DynamicUser=yes", and the error message 
comes from 
systemd.execute.c.
 It's complaining about the /etc/.pwd.lock file (see journal below).

I turned on debug (systemd-analyze set-log-level debug) and then attempted to 
start the rdisc.service.  This is an extract from the journal:

$ journalctl -f
:

Sep 14 03:26:19 sph-093-rmc systemd[1]: rdisc.service: Forked /sbin/rdisc as 
24873

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: Cannot open /etc/.pwd.lock: Too 
many levels of symbolic links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed to update 
dynamic user credentials: Too many levels of symboli

c links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed at step USER 
spawning /sbin/rdisc: Too many levels of symbolic

 links

Sep 14 03:26:19 sph-093-rmc systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freed

I can override it with "DynamicUser=no" and the service starts.  However, I'm 
trying to understand why it reports "too many levels of symbolic links". The 
lock file is a single-level symlink to a file in sysconfig.  (This is an 
embedded device, where /etc is read-only and /etc/sysconfig is writeable).


$ ls -l /etc/.pwd.lock

lrwxrwxrwx 1 root root 19 Apr  5  2011 /etc/.pwd.lock -> sysconfig/.pwd.lock

$ ls -l /etc/sysconfig/.pwd.lock

-rw--- 1 root root 0 Aug 16 07:25 /etc/sysconfig/.pwd.lock

For the purpose of investigation, I configured an overlay so /etc/.pwd.lock was 
a simple writeable file (not a read-only symlink) and the service starts.

Why is systemd complaining about the file being a symlink?

Regards,
Matt.

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

[Jeremy Friesner]

Kevin P. Fleming 
>
 wrote:

> I believe you want KeepConfiguration="static".

Thanks for the suggestion; I tried that, but it didn’t change the behavior 
AFAICT.  From the documentation, the KeepConfiguration setting seems to govern 
what networkd does when networkd is started or stopped, so it seems unlikely 
that the KeepConfiguration setting would apply in the event where an Ethernet 
cable is connected or disconnected.

Jeremy
NOTICE: This email may contain confidential information. Please see 
https://meyersound.com/legal/#email-policy for our complete policy.

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.

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

[Jeremy Friesner]

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.