Summary
When manage_networkd => true and networkd_ensure => 'stopped', Puppet fails the idempotency check on Archlinux rolling (systemd 260+). On every subsequent run, Puppet reports that systemd-networkd was changed from running to stopped, even though it was stopped by the previous run.
This has been causing the Distro Puppet - Archlinux rolling acceptance job to fail on every CI run since at least February 2026.
Root Cause
Systemd 260 introduced additional socket units for systemd-networkd:
systemd-networkd-varlink.socket
systemd-networkd-varlink-metrics.socket
systemd-networkd-resolve-hook.socket
These join the long-standing systemd-networkd.socket. All four are listed in the service's Sockets= directive and act as socket activation triggers. When systemd-networkd.service is stopped but these socket units remain active, systemd immediately re-spawns the service:
systemd[1]: Stopped Network Management.
systemd[1]: Starting Network Management... ← immediate restart
systemd[1]: Started Network Management.
Older systemd versions (Debian 12: 252, Ubuntu 24.04: 255) only ship systemd-networkd.socket, which does not exhibit this behaviour.
Steps to Reproduce
Run the following in a privileged Archlinux container with systemd as PID 1:
docker run -d --privileged --tmpfs /tmp --tmpfs /run --tmpfs /run/lock \
-v /sys/fs/cgroup:/sys/fs/cgroup:rw --cgroupns=host \
--name arch-test archlinux/archlinux /sbin/init
# wait for systemd to start
sleep 5
docker exec arch-test systemctl is-active systemd-networkd
# → active
docker exec arch-test systemctl stop systemd-networkd
docker exec arch-test systemctl is-active systemd-networkd
# → active (immediately restarted)
docker exec arch-test systemctl list-units --no-pager 'systemd-networkd*.socket'
# → 4 socket units all active
Install the module and apply the manifest twice, observing the second run makes changes:
docker exec arch-test pacman --sync --noconfirm puppet
docker exec arch-test puppet module install puppetlabs-stdlib
# copy module into container
docker cp . arch-test:/etc/puppetlabs/code/modules/systemd
class { 'systemd':
manage_networkd => true,
networkd_ensure => 'stopped',
}
# First run
Notice: /Stage[main]/Systemd::Networkd/Service[systemd-networkd]/ensure: ensure changed 'running' to 'stopped'
# Second run — should produce no changes, but:
Notice: /Stage[main]/Systemd::Networkd/Service[systemd-networkd]/ensure: ensure changed 'running' to 'stopped'
Summary
When
manage_networkd => trueandnetworkd_ensure => 'stopped', Puppet fails the idempotency check on Archlinux rolling (systemd 260+). On every subsequent run, Puppet reports thatsystemd-networkdwas changed fromrunningtostopped, even though it was stopped by the previous run.This has been causing the
Distro Puppet - Archlinux rollingacceptance job to fail on every CI run since at least February 2026.Root Cause
Systemd 260 introduced additional socket units for
systemd-networkd:systemd-networkd-varlink.socketsystemd-networkd-varlink-metrics.socketsystemd-networkd-resolve-hook.socketThese join the long-standing
systemd-networkd.socket. All four are listed in the service'sSockets=directive and act as socket activation triggers. Whensystemd-networkd.serviceis stopped but these socket units remain active, systemd immediately re-spawns the service:Older systemd versions (Debian 12: 252, Ubuntu 24.04: 255) only ship
systemd-networkd.socket, which does not exhibit this behaviour.Steps to Reproduce
Run the following in a privileged Archlinux container with systemd as PID 1:
Install the module and apply the manifest twice, observing the second run makes changes: