Am 14.08.2018 um 00:09 schrieb Bernhard Schmidt: > Hi, > > 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.
Would be interesting to know, why exactly the file in /etc is not taking precedence: a/ Is it because of the template b/ Is it because of you generate the symlink in /run/systemd/generator/openvpn.service.wants > Are my expectations wrong? Is this a bug somewhere? My first instinct was, that yes, a file in /etc should take precedence over the one from /lib, as everything else would be inconsistent. There might be an underlying reason for this behaviour which I don't know of or maybe it's simply a bug. Would probably be a good idea to raise this on the upstream mailing list. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
