В Mon, 18 Aug 2014 19:22:01 +0200
Lennart Poettering <lenn...@poettering.net> пишет:

> On Mon, 18.08.14 21:10, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
> > If foo@bar.service symlink is present, it is impossible to enable it:
> > 
> > bor@opensuse:~> ll /run/systemd/system
> > итого 8
> > lrwxrwxrwx 1 root root   32 авг 18 21:06 foo@bar.service -> 
> > /run/systemd/system/foo@.service
> > -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo@.service
> > bor@opensuse:~> sudo systemctl enable foo@bar.service
> > Failed to issue method call: No such file or directory
> > bor@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?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to