Description of problem: systemctl disable foo.service works only for service files from /etc/* for service files in /lib/*, if the service is enabled, it displays "Unit files contain no appliccable instalation information. Ignoring" if the service is disabled, does not display anything. Version-Release number of selected component (if applicable): 26-8 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Example: # systemctl enable sshd.socket # ls -l /lib/systemd/system/*wants/ | grep -i sshd # ls -l /etc/systemd/system/*wants/ | grep -i sshd lrwxrwxrwx. 1 root root 31 Jul 26 16:45 sshd.socket -> /lib/systemd/system/sshd.socket # systemctl disable sshd.socket rm '/etc/systemd/system/sockets.target.wants/sshd.socket' The link was removed. But: # ls /lib/systemd/system/multi-user.target.wants/rc-local.service -l lrwxrwxrwx. 1 root root 36 Jul 18 15:43 /lib/systemd/system/multi-user.target.wants/rc-local.service -> /lib/systemd/system/rc-local.service # systemctl disable rc-local.service Unit files contain no applicable installation information. Ignoring. # ls /lib/systemd/system/multi-user.target.wants/rc-local.service -l lrwxrwxrwx. 1 root root 36 Jul 18 15:43 /lib/systemd/system/multi-user.target.wants/rc-local.service -> /lib/systemd/system/rc-local.service The link was not removed.
Services with links in /lib aren't admin-modifiable in the same way - this is intentional. The corresponding example would be the S99 start link for rc.local in the old system, which was not manageable via chkconfig. If you really want to disable it, do 'ln -s /dev/null /etc/systemd/system/rc-local.service'
Thank you. Is this documented somewhere? Because, since most of the services are ("enabled") in /lib, this makes them hardly manageable by design, if i understand this correctly. Is there another way those links can be managed?
The masking via symlinks to /dev/null is mentioned at: http://0pointer.de/blog/projects/three-levels-of-off It's certainly possible to clarify the documentation to mention that enable/disable only change links in /etc, not /lib. Reopening.
Thank you very much!
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Maybe this is related to the trouble I am having in F16. systemctl disable sendmail.service says it is doing so, but whenever I boot up sendmail starts again. systemctl enable vsftpd says it is enabling, but whenever I boot up the service does not start.
(In reply to comment #7) > Maybe this is related to the trouble I am having in F16. > systemctl disable sendmail.service says it is doing so, but whenever I > boot up sendmail starts again. This looks like bug 748416 that should be fixed in sendmail-8.14.5-10.fc16. > systemctl enable vsftpd says it is enabling, but whenever > I boot up the service does not start. See bug 753365.
Well I have sendmail-8.14.5-10.fc16.i686 installed and I repeated the systemctl disable sendmail.service command and sendmail started up again when I rebooted. Says I am not authorized to see bug 748416.
That's weird. I see no flags set in bug 748416 that would make it non-public. sendmail consists of two units: sendmail.service and sm-client.service They both have Wants=... set for each other. You may have to disable sm-client.service too. I think this mutual pulling of units is suboptimal and you should report it as a bug against the sendmail package.
Thanks. Disabling both of them seems to have fixed it. Life gets more complicated with each new release. On the web page the text 'bug 748416' has a line drawn through it, so maybe it's not there anymore?
(In reply to comment #11) > Thanks. Disabling both of them seems to have fixed it. Life gets more > complicated with each new release. I disagree and I repeat myself: report it as a bug. > On the web page the text 'bug 748416' has a line drawn through it, > so maybe it's not there anymore? No, it means that the bug is in the state CLOSED (because it's been resolved by ERRATA, i.e. a package update). The complete text of the bug is still public. It loads fine for me even when I'm not authenticated to Bugzilla. Anyway, the problem resolved in that bug was that /etc/NetworkManager/dispatcher.d/10-sendmail used "systemctl restart sendmail.service" instead of the correct "systemctl try-restart sendmail.service".
(In reply to comment #4) > The masking via symlinks to /dev/null is mentioned at: > http://0pointer.de/blog/projects/three-levels-of-off > > It's certainly possible to clarify the documentation to mention that > enable/disable only change links in /etc, not /lib. Reopening. Hum what's unclear here? "This removes all symlinks to the specified unit files from the unit configuration directory." Do you want replace "unit configuration directory" with "/etc/systemd/system" ?
I'm going to close this one since the man pages already mentions "This removes all symlinks to the specified unit files from the unit configuration directory." And unit configuration directory is "/etc/systemd" Feel free to reopen with suggestions on how you would like this rephrased in the man page if the above is not clear enough. Thanks