Description of problem: Have a working systemd machine. 'systemctl list-unts' sees various services active that one wants disabled: # systemctl stop fedora-storage-init-late.service # systemctl stop fedora-storage-init.service # systemctl disable fedora-storage-init-late.service # systemctl disable fedora-storage-init.service # systemctl disable rpcbind.target Reboot and afterwards: # systemctl list-units shows: ... fedora-storage-init-late.service loaded active exited .... fedora-storage-init.service loaded active exited .... ... rpcbind.target loaded active active ... But on the other hand, disabling in the same manner for example remote-fs.service does actually disable the service. In Mageia 2 all of such 'disable' actions should really work, IMHO.
Blocks: (none) => 2120
what are the complete output of those commands ?
CC: (none) => dmorganec
There was no output at all that I could see (other than reported above).
what about this bug with systemd 40 ?
My last bootup was with systemd 40 installed and the problem was still the same as posted.
Some services are enabled "statically", that is they are hard deps of other services. e.g.: [colin@jimmy ~]$ systemctl status rpcbind.target rpcbind.target - RPC Port Mapper Loaded: loaded (/lib/systemd/system/rpcbind.target; static) Active: active since Tue, 14 Feb 2012 16:54:15 +0000; 18min ago Notice the word "static" there. This means that there is a hard require on something else. In this particular case this file makes it static: /lib/systemd/system/multi-user.target.wants/rpcbind.target As you can see this is in the "/lib" tree rather than the "/etc" tree. The difference between /lib and /etc is the the the former is reserved for packaging and the latter for user actions. [colin@jimmy ~]$ rpm -qf /lib/systemd/system/multi-user.target.wants/rpcbind.target systemd-units-40-2.mga2 So in this case, rpcbind.target is a hard requirement of multi-user.target. Also in this case if you look at "man systemd.special" you will see: rpcbind.target systemd automatically adds dependencies of type After for this target unit to all SysV init script service units with an LSB header referring to the $rpcbind facility. So it's really not something you want to disable until all sysvinit systems are completly nuked otherwise problems will occur. The other services you mention are similarly forced on in the packaging. It may be that we need to revise this decision however. As the storage-init services should be noops when not needed, I do not think it's a net gain to allow administrators to disable them and end up with a broken system. Far better to always have them enabled. If you feel very strongly about this you can mask the service by creating a file in /etc/systemd/system/$name.service which is a symlink to /dev/null and it will be permanently nuked. I agree however that there is some discrepancy between rpcbind.target and remote-fs.service however targets are a little different to services and as such I think this is OK and acceptable. It is certainly not appropriate that any given "disable" operation should magically world. If dependencies are involved should it also disable the services that depend on it, or should it fail? As I said, some services are static, but I agree that better information should be returned to the user when a given action does not succeed (I have some other niggles myself regarding enabling template units) i.e. I'd like "systemctl enable openvpn@home.service" to work as expected rather than throwing up a confusing error. But IMO these kind of UI discussions are better had upstream on IRC or mailing lists or via their bugtracker rather than downstream with us.
CC: (none) => mageia
Considering the above comment (I noticed a typo: "magically world" should be "magically work"), I think we can close this as invalid. I would still welcome better feedback to users, but this is very much an upstream issue.
Status: NEW => RESOLVEDResolution: (none) => INVALID