[systemd-devel] Impossible to enable instantiated symlink (foo@bar)
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
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! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
В 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
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
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
