Bug 725747 - systemctl disable does not work as expected - clarify man page?
systemctl disable does not work as expected - clarify man page?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-07-26 08:51 EDT by cornel panceac
Modified: 2012-02-02 17:52 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-02 17:52:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cornel panceac 2011-07-26 08:51:02 EDT
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:
Comment 1 cornel panceac 2011-07-26 10:12:25 EDT
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.
Comment 2 Bill Nottingham 2011-07-26 12:10:28 EDT
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'
Comment 3 cornel panceac 2011-07-26 13:21:16 EDT
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?
Comment 4 Bill Nottingham 2011-07-26 13:48:46 EDT
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.
Comment 5 cornel panceac 2011-07-26 14:16:58 EDT
Thank you very much!
Comment 6 Fedora Admin XMLRPC Client 2011-10-20 12:29:34 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Jim Haynes 2011-11-11 21:32:36 EST
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@vsftpd.service says it is enabling, but whenever
I boot up the service does not start.
Comment 8 Michal Schmidt 2011-11-14 04:41:59 EST
(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@vsftpd.service says it is enabling, but whenever
> I boot up the service does not start.

See bug 753365.
Comment 9 Jim Haynes 2011-11-14 11:13:08 EST
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.
Comment 10 Michal Schmidt 2011-11-14 11:41:21 EST
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.
Comment 11 Jim Haynes 2011-11-14 20:56:08 EST
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?
Comment 12 Michal Schmidt 2011-11-15 02:23:26 EST
(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".
Comment 13 Jóhann B. Guðmundsson 2012-01-25 07:28:01 EST
(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" ?
Comment 14 Jóhann B. Guðmundsson 2012-02-02 17:52:07 EST
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

Note You need to log in before you can comment on or make changes to this bug.