Bug 827288 - rpcbind does not want to be disabled.
rpcbind does not want to be disabled.
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
: Reopened
: 1069380 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 23:32 EDT by Hin-Tak Leung
Modified: 2015-06-29 21:21 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 21:21:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
"systemctl show rpcbind.service rpcbind.socket" result (5.50 KB, application/octet-stream)
2012-10-15 10:03 EDT, Hin-Tak Leung
no flags Details

  None (edit)
Description Hin-Tak Leung 2012-05-31 23:32:32 EDT
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.
Comment 1 openwiki 2012-07-04 13:00:52 EDT
systemctl disable rpcbind.socket  -> ok
systemctl disable rpcbind.service -> ok

But after reboot
rpcbind service come back.
Comment 2 Steve Dickson 2012-10-13 10:13:06 EDT
I'm thinking this is probably a systemd issue than a rpcbind issue.. reassigning
Comment 3 Michal Schmidt 2012-10-15 08:47:21 EDT
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
Comment 4 Hin-Tak Leung 2012-10-15 10:03:36 EDT
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.
Comment 5 Michal Schmidt 2012-10-15 10:55:59 EDT
(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
Comment 6 Hin-Tak Leung 2012-10-15 12:16:39 EDT
(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?
Comment 7 Michal Schmidt 2012-10-15 12:36:26 EDT
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
Comment 8 Michal Schmidt 2012-10-15 12:38:34 EDT
I see that nfs.service is actually an alias for nfs-server.service, so no need to check that one twice.
Comment 9 Michal Schmidt 2012-10-15 12:51:25 EDT
(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.
Comment 10 Jóhann B. Guðmundsson 2012-10-15 12:57:00 EDT
It should be enough to just disable the nfs.target to disable nfs altogether at least that was the plan...
Comment 11 Michal Schmidt 2012-10-15 13:04:18 EDT
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.
Comment 12 Jóhann B. Guðmundsson 2012-10-15 13:09:04 EDT
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.
Comment 13 Michal Schmidt 2012-10-15 13:17:30 EDT
> 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.
Comment 14 Jóhann B. Guðmundsson 2012-10-15 13:28:59 EDT
(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...
Comment 15 Steve Dickson 2012-10-15 16:46:28 EDT
(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...
Comment 16 Lennart Poettering 2013-01-14 15:46:50 EST
Reassigning to NFS.

Please use PartOf like this:

in your individual NFS services add PartOf=nfs.target, drop all Requires= bits for that.
Comment 17 Fedora End Of Life 2013-07-03 23:29:09 EDT
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.
Comment 18 Fedora End Of Life 2013-08-01 07:04:55 EDT
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.
Comment 19 Gabriel Somlo 2014-02-24 16:49:24 EST
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 ?
Comment 20 Gabriel Somlo 2014-02-24 16:50:39 EST
*** Bug 1069380 has been marked as a duplicate of this bug. ***
Comment 21 Gabriel Somlo 2014-02-24 16:58:43 EST
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 :)
Comment 22 Fedora End Of Life 2015-05-29 04:44:59 EDT
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.
Comment 23 Fedora End Of Life 2015-06-29 21:21:47 EDT
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.

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