[systemd-devel] Impossible to enable instantiated symlink (foo at bar)

[Lennart Poettering]

On Mon, 18.08.14 21:52, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> 
> В Mon, 18 Aug 2014 19:22:01 +0200
> Lennart Poettering <lennart at poettering.net> пишет:
> 
> > On Mon, 18.08.14 21:10, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
> > 
> > > If foo at bar.service symlink is present, it is impossible to enable it:
> > > 
> > > bor at opensuse:~> ll /run/systemd/system
> > > итого 8
> > > lrwxrwxrwx 1 root root   32 авг 18 21:06 foo at bar.service -> /run/systemd/system/foo at .service
> > > -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo at .service
> > > bor at opensuse:~> sudo systemctl enable foo at bar.service
> > > Failed to issue method call: No such file or directory
> > > bor at opensuse:~> 
> > > 
> > > The problem is, unit_file_search() is called with allow_symlink=false
> > > when used in enable codepath, which means that every attempt to open
> > > will end up wither in ELOOP or ENOENT. At the end it exits with the
> > > last error (ENOENT in this case, but this obviously depends on in which
> > > directory symlink is created).
> > > 
> > > Is it really intentional? I'm actually all for disallowing such
> > > symlinks :) but in this case at least meaningful error message is
> > > required.
> > 
> > Happy to take a patch which fixes the error to ELOOP if we hit ELOOP at
> > least once!
> > 
> 
> On a minor note, I do not think "Too many symbolic links encountered"
> would be better error message here.
> 
> But more seriously - this is highly inconsistent. In this case such
> synlinks must be disallowed everywhere - currently "systemctl enable"
> fails but "systemctl start" succeeds.
> 
> So I have to ask once more - is intention to disallow such symlinks
> globally?

No.

Symlinks are what "systemctl enable" and "systemctl disable" manage,
based on the data of [Install] sections. We want to make sure that
clearly separate the configuration state from the vendor data here,
hence never follow symlinks when enabling/disabling something, but we do
follow them with "systemctl start" and "systemctl stop" during runtime.

Lennart

-- 
Lennart Poettering, Red Hat