On Mon, 18.08.14 21:52, Andrei Borzenkov (arvidj...@gmail.com) wrote: > > В 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?
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
