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

[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.

Are my expectations wrong? Is this a bug somewhere?

Note that adding something to
/etc/systemd/system/openvpn at .service.d/override.conf IS taken into account

   Loaded: loaded (/lib/systemd/system/openvpn at .service;
enabled-runtime; vendor preset: enabled)
  Drop-In: /etc/systemd/system/openvpn at .service.d
           └─override.conf

It's just the whole copy-and-edit override that doesn't work.

Bernhard