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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 16.08.18 00:48, Bernhard Schmidt (berni@xxxxxxxxxxxxx) wrote:

> 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

As Mantas already indicated: The full path contained in the symlink
does not matter immediately: we will always look in the regular search
paths first, so that stuff in /etc and /run can override things. The
full path is only used if the unit file doesn't otherwise appear in
the search path, i.e. as a last resort. If you are seeing other
behaviour on current systemd versions, that'd be a bug. Please file it
on github and we'll look into it.

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel