Description of problem: rpcbind does not want to be disabled. #netstat -n -p -a | grep rpc tcp 0 0 0.0.0.0:36234 0.0.0.0:* LISTEN 890/rpc.statd tcp 0 0 0.0.0.0:875 0.0.0.0:* LISTEN 970/rpc.rquotad tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 863/rpcbind tcp 0 0 0.0.0.0:20048 0.0.0.0:* LISTEN 963/rpc.mountd tcp6 0 0 :::111 :::* LISTEN 863/rpcbind tcp6 0 0 :::20048 :::* LISTEN 963/rpc.mountd tcp6 0 0 :::37816 :::* LISTEN 890/rpc.statd udp 0 0 0.0.0.0:20048 0.0.0.0:* 963/rpc.mountd udp 0 0 0.0.0.0:606 0.0.0.0:* 863/rpcbind udp 0 0 127.0.0.1:642 0.0.0.0:* 890/rpc.statd udp 0 0 0.0.0.0:43742 0.0.0.0:* 890/rpc.statd udp 0 0 0.0.0.0:875 0.0.0.0:* 970/rpc.rquotad udp 0 0 0.0.0.0:111 0.0.0.0:* 863/rpcbind udp6 0 0 :::20048 :::* 963/rpc.mountd udp6 0 0 :::606 :::* 863/rpcbind udp6 0 0 :::111 :::* 863/rpcbind udp6 0 0 :::36034 :::* 890/rpc.statd unix 2 [ ACC ] STREAM LISTENING 20524 863/rpcbind /var/run/rpcbind.sock unix 2 [ ACC ] STREAM LISTENING 15324 1/systemd /var/run/rpcbind.sock unix 3 [ ] STREAM CONNECTED 21135 964/rpc.idmapd unix 3 [ ] STREAM CONNECTED 21134 964/rpc.idmapd unix 2 [ ] DGRAM 20406 963/rpc.mountd unix 2 [ ] DGRAM 20669 890/rpc.statd They keep coming back after doing: # systemctl --no-reload stop rpcbind.service # systemctl --no-reload stop rpcbind.socket # systemctl --no-reload disable rpcbind.socket # systemctl --no-reload disable rpcbind.service (I added the no-reload recently, but with or without, it had not worked). Version-Release number of selected component (if applicable): # rpm -q systemd systemd-44-12.fc17.x86_64 systemd-44-12.fc17.i686 # rpm -q rpcbind rpcbind-0.2.0-16.fc17.x86_64 How reproducible: Steps to Reproduce: 1. # systemctl --no-reload stop rpcbind.service # systemctl --no-reload stop rpcbind.socket # systemctl --no-reload disable rpcbind.socket # systemctl --no-reload disable rpcbind.service # systemctl --no-reload | grep rpc rpcbind.service loaded failed failed RPC bind service 2. reboot 3. Actual results: the rpc processes keep coming back Expected results: rpc processes disabled. Additional info: Was in f16, just annoying enough now to file a report.
systemctl disable rpcbind.socket -> ok systemctl disable rpcbind.service -> ok But after reboot rpcbind service come back.
I'm thinking this is probably a systemd issue than a rpcbind issue.. reassigning
Do you have ypbind enabled? ypbind.service says: Requires=rpcbind.service If that's not the case, please attach the output of: systemctl show rpcbind.service rpcbind.socket
Created attachment 627455 [details] "systemctl show rpcbind.service rpcbind.socket" result systemctl show rpcbind.service rpcbind.socket *Note* though I got so fed up with this, I added /etc/rc.d/rc.local a few systemctl commands to make sure a few things are disabled. So I'll let others to submit their more troublesome versions of theirs. No, I don't have ypbind.service enabled.
(In reply to comment #4) > Created attachment 627455 [details] > "systemctl show rpcbind.service rpcbind.socket" result It shows: RequiredBy=nfs-server.service ypbind.service So perhaps it's nfs-server.service that's pulling it in? > *Note* though I got so fed up with this, I added /etc/rc.d/rc.local a few > systemctl commands to make sure a few things are disabled. For a slightly less ugly workaround I suggest you familiarize yourself with the concept of unit 'masking': man systemctl # look for "mask [NAME...]" http://0pointer.de/blog/projects/three-levels-of-off.html
(In reply to comment #5) > (In reply to comment #4) > > Created attachment 627455 [details] > > "systemctl show rpcbind.service rpcbind.socket" result > > It shows: > RequiredBy=nfs-server.service ypbind.service > > So perhaps it's nfs-server.service that's pulling it in? No don't have nfs-server.service running, although # systemctl |grep nfs proc-fs-nfsd.mount loaded active mounted RPC Pipe File System Which means I should add another two disable+stop line to my rc.local. > > *Note* though I got so fed up with this, I added /etc/rc.d/rc.local a few > > systemctl commands to make sure a few things are disabled. > > For a slightly less ugly workaround I suggest you familiarize yourself with > the concept of unit 'masking': > man systemctl # look for "mask [NAME...]" > http://0pointer.de/blog/projects/three-levels-of-off.html I do not want masking. I just want software installed but not used, until I start them manually. Surely that's a common need i.e. "installing a piece of software for experimenting/testing or occasional use, not daily use", and a definite regression from sysv?
The following units have "Requires=rpcbind.service" on my system: nfs-lock.service nfs-server.service nfs.service ypbind.service Please check if any of them could be the one that pulls in rpcbind.service on your system. Otherwise please generate a debug log ('dmesg.txt') by following the instructions here: http://freedesktop.org/wiki/Software/systemd/Debugging#If_You_Can_Get_a_Shell
I see that nfs.service is actually an alias for nfs-server.service, so no need to check that one twice.
(In reply to comment #7) > The following units have "Requires=rpcbind.service" on my system: > nfs-lock.service > nfs-server.service > nfs.service > ypbind.service Oh, and there's also: nfs.target which may be enabled and pulls in rpcbind, and: rpcidmapd.service rpcsvcgssd.service which have requirement dependencies on nfs-server.service.
It should be enough to just disable the nfs.target to disable nfs altogether at least that was the plan...
The whole bunch of NFS-related units seems to be entangled with requirement dependencies. Perhaps some of them are excessive and should be reconsidered. Perhaps some of them would work better as "PartOf=" dependencies. And systemd could help with troubles like this BZ by: 1. remembering the reason for the activation of each unit. 2. providing a nice tool to list requirement and ordering dependencies recursively, or to resolve questions about the graph of dependencies in a useful way.
When the units where written "PartOf=" did not exist and the plan was to update all units in the distribution to more current state as a part of the cleanup process. I assume FESCO are the ones that are eventually going to do that since they rejected that feature to begin with.
> I assume FESCO are the ones that are eventually going to do > that since they rejected that feature to begin with. You know very well that's a silly assumption. Also, one does not need an official Feature to improve unit files.
(In reply to comment #13) > > I assume FESCO are the ones that are eventually going to do > > that since they rejected that feature to begin with. > > You know very well that's a silly assumption. > Also, one does not need an official Feature to improve unit files. The cleanup process was a bit more than that + the PartOf= feature needs to be back ported to all GA releases and or silently ignore on those it cant since maintainers do not want to carry different unit files for different GA release. Looking at systemd that does not seem to be the case for PartOf which btw you only backported to F17 last Friday but yes the intent was to go through and update all unit files to take advantage of PartOf where it was applicable which certainly is the case for the nfs services...
(In reply to comment #12) > When the units where written "PartOf=" did not exist and the plan was to > update all units in the distribution to more current state as a part of the > cleanup process. If you could open up another bz against nfs-utils and give me an example of what needs to happen.. I'll try to make it happen...
Reassigning to NFS. Please use PartOf like this: in your individual NFS services add PartOf=nfs.target, drop all Requires= bits for that.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This still happens on F20; I'm kickstarting with "services --disable=rpcbind", but rpcbind gets fired up anyway each time I reboot because of "nfs.target". Is there any way to disable nfs.target without de-selecting the software during build ? Preferably in kickstart, even in %post if there's no better alternative ?
*** Bug 1069380 has been marked as a duplicate of this bug. ***
partially answering my own question: "ln -s /dev/null /etc/systemd/system/nfs.target" takes care of the problem for me (and can be added to a kickstart %post section, which is nice). It still feels like a bigger hammer than absolutely necessary :)
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.