Does a generator need to take care of overrides in /etc?

[Michael Biebl]

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 at .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 at test1.service
> ● openvpn at test1.service - OpenVPN connection to test1
>    Loaded: loaded (/lib/systemd/system/openvpn at .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 at test2.service
> # systemctl status openvpn at test2.service
> ● openvpn at test2.service - OpenVPN connection to test2
>    Loaded: loaded (/etc/systemd/system/openvpn at .service; disabled;
> vendor preset: enabled)
>   Process: 334 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS)
> 
> So openvpn at 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 at test1.service ->
> /lib/systemd/system/openvpn at .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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180814/39950547/attachment-0002.sig>