On Mon, Sep 10, 2018 at 8:49 PM Lennart Poettering <lenn...@poettering.net> wrote:
> On Do, 16.08.18 00:48, Bernhard Schmidt (be...@birkenwald.de) 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. > I see it has been filed as <https://github.com/systemd/systemd/issues/9921>. -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
