Hi, I've been sent here by the great systemd maintainers in Debian for clarification. The situation was observed on systemd v239 on Debian unstable.
On src:openvpn we have recently gotten a bug report about local modifications of the openvpn@.service file in /etc being ignored when the instance is started by the systemd generator, because the generator unconditionally links to the file in /lib/systemd and does not check for the presence of a modified file in /etc/systemd https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905392 My first instinct was that this could not be true, as it would be the complete opposite to my expectations as regular systemd user, where overriding something in /etc (either by copying and modifying the .service file, or by adding dropins in .service.d) is adhered to by all systemd management commands. But I can reproduce this in a sid container (please ignore the activating/failed status below, openvpn in the container could not create a tun device, just look at the path to the unit and to the ExecStart line /etc/openvpn# openvpn --genkey --secret static.key /etc/openvpn# head test1.conf dev tun ifconfig 10.1.0.1 10.1.0.2 secret static.key # cp /lib/systemd/system/openvpn\@.service /etc/systemd/system # sed -ri 's:ExecStart=.+$:ExecStart=/bin/sleep 10:' /etc/systemd/system/openvpn\@.service # reboot # systemctl status openvpn@test1.service ● openvpn@test1.service - OpenVPN connection to test1 Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled-runtime; vendor preset: enabled) [...] Process: 231 ExecStart=/usr/sbin/openvpn --daemon ovpn-test1 --status /run/openvpn/test1.status 10 --cd /etc/openvpn --config /etc/openvpn/test1.conf --writepid /run/openvpn/test1.pid (code=exited, status=1/ Main PID: 231 (code=exited, status=1/FAILURE) # systemctl start openvpn@test2.service # systemctl status openvpn@test2.service ● openvpn@test2.service - OpenVPN connection to test2 Loaded: loaded (/etc/systemd/system/openvpn@.service; disabled; vendor preset: enabled) Process: 334 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) So openvpn@test1.service (that is .wants by the generator) is using the shipped configuration, but any other instance is using the version in /etc as expected. /run/systemd/generator/openvpn.service.wants# ls -la lrwxrwxrwx 1 root root 36 Aug 13 23:54 openvpn@test1.service -> /lib/systemd/system/openvpn@.service The proposed fix indeed changes this by checking the existence of the file in /etc first and symlinking to this, but I would not have expected the logic for overriding configuration in /etc necessary to be implemented in each and every generator. Are my expectations wrong? Is this a bug somewhere? Note that adding something to /etc/systemd/system/openvpn@.service.d/override.conf IS taken into account Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled-runtime; vendor preset: enabled) Drop-In: /etc/systemd/system/openvpn@.service.d └─override.conf It's just the whole copy-and-edit override that doesn't work. Thanks, Bernhard _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
