Fedora 25 and disabling whatever is listening on port 111
Solution 1
When you run sudo systemctl disable rpcbind
on Fedora 25
I think there is a warning:
Warning: Stopping rpcbind.service, but it can still be activated by:
rpcbind.socket
So you can try following:
sudo systemctl stop rpcbind.socket
sudo systemctl disable rpcbind.socket
Solution 2
It is socket activation :). And you were right to be suspicious.
You need to disable rpcbind.socket
. Disabling rpcbind.service
- which is what systemctl disable rpcbind
assumes - has no effect.
Also, the disable
here will only affect what happens at boot time. So if you want to see an immediate change, you also want to run systemctl stop rpcbind.socket
.
EDIT: This question looks very similar to me. Jeff Schaller points out you can use the command systemctl list-sockets
, to see the ports and services which systemd
is implementing socket activation for.
I went back and had a look at Fedora-Workstation-Live-x86_64-25-1.3.iso
.
The status of rpcbind.service shows indirect; vendor preset; disabled
. (Also Active: inactive (dead)
). So it's clear disabling (or stopping) it again would not change anything.
I guess the indirect
here is a hint to look out for other units which activate this one (including but not limited to socket units). Once the socket unit is stopped as well, it changes from indirect
to disabled
.
The strange part is that the socket unit shows as enabled; vendor preset: disabled
. This means something has enabled rpcbind.socket in the Fedora 25 image, but it was not enabled by /lib/systemd/system-preset/80-workstation.preset
or 90-default.preset
. This appears to go against the (current) policy at https://fedoraproject.org/wiki/Packaging:DefaultServices which is linked to from 90-default.preset -
If the service should be enabled by default, it must be added to one of the distribution presets files.
This has been resolved at some point. rpcbind.socket
is no longer enabled in Fedora-Workstation-Live-x86_64-28-1.1.iso
.
(This does not mean that rpcbind / port 111 is automatically accessible from the network on systems installed from a Fedora 25 disk. The install also includes a firewall which does not allow port 111)
Solution 3
Port 111 is linked to to portmap. If you use NFS chances are you will need it. You can use systemctl -a | grep -E "rpc|port"
to see the name of the corresponding service and disable it (I don't have access to a Fedora box at the time).
Solution 4
This port is activated by the nfs
service, installed from the nfs-utils
package. If you don't need it you'd better uninstall it. nfs-utils
and iscsi-initiator-utils
are usually installed as dependencies of libvirt
package. Both packages activate a plenty of services and sockets you might not have wanted. This commands can be used in order to disable nfs
and iscsi-initiator-utils
services.
systemctl disable nfs-client.target
systemctl stop nfs-client.target
systemctl disable rpcbind.socket
systemctl stop rpcbind.socket
systemctl stop rpc_pipefs.target
systemctl stop rpcbind.target
systemctl stop rpcbind.service
systemctl disable rpcbind.service
systemctl stop var-lib-nfs-rpc_pipefs.mount
systemctl stop proc-fs-nfsd.mount
systemctl disable gssproxy.service
systemctl stop gssproxy.service
modprobe -r sunrpc
systemctl disable iscsid.socket
systemctl stop iscsid.socket
systemctl disable iscsiuio.socket
systemctl stop iscsiuio.socket
systemctl disable iscsid.service
systemctl stop iscsid.service
systemctl disable iscsiuio.service
systemctl stop iscsiuio.service
Related videos on Youtube
Admin
Updated on September 18, 2022Comments
-
Admin over 1 year
I've got a Fedora 25 x86_64 stand alone workstation. Something is listening on port 111 (identified with an nmap scan):
$ sudo lsof -i :111 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 36u IPv4 15170 0t0 TCP *:sunrpc (LISTEN) systemd 1 root 37u IPv4 15171 0t0 UDP *:sunrpc systemd 1 root 38u IPv6 15172 0t0 TCP *:sunrpc (LISTEN) systemd 1 root 39u IPv6 15173 0t0 UDP *:sunrpc
I disabled the Sun gear on the port with the following commands:
$ sudo systemctl disable rpcbind $ sudo systemctl disable sunrpc Failed to disable unit: No such file or directory
After reboot the port is still open.
It appears something other than Sun gear wants to listen on port 111. Or maybe
systemd
is not respecting my wishes to disable the unused service. Or maybe something else...How do I determine what is trying to listen on the port, and how do I disable it?
From below:
$ sudo systemctl -a | grep -E "rpc|port" var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System abrtd.service loaded active running ABRT Automated Bug Reporting Tool auth-rpcgss-module.service loaded inactive dead Kernel Module supporting RPCSEC_GSS fedora-import-state.service loaded active exited Import network configuration from initramfs fedora-readonly.service loaded active exited Configure read-only root support rpc-gssd.service loaded inactive dead RPC security service for NFS client and server rpc-statd-notify.service loaded inactive dead Notify NFS peers of a restart rpc-statd.service loaded inactive dead NFS status monitor for NFSv2/3 locking. ● rpc-svcgssd.service not-found inactive dead rpc-svcgssd.service rpcbind.service loaded inactive dead RPC Bind rpcbind.socket loaded active listening RPCbind Server Activation Socket rpc_pipefs.target loaded active active rpc_pipefs.target rpcbind.target loaded active active RPC Port Mapper
-
user2948306 almost 7 yearsI didn't see that message when I was testing it myself. I think the problem is rpcbind.service isn't enabled or started in the first place (by default, and unless it gets activated)? So it sees the service is already disabled, and terminates before reaching the message. Should probably be improved.
-
Admin almost 7 yearsThanks @sourcejedi. Disabling
sunrpc
andrpcbind
did not stop the listener. -
user2948306 almost 7 yearsKind of noisy to look through - 13 lines of output, and the output suffers from not being able to access the tty directly.
-
Admin almost 7 yearsThanks @sourcejedi. I've got to get to work so I don't have time to dig into this deeper right now. You got my upvote. Why do people think its a good idea to break simple processes that have been around for years and always "just worked"... xkcd.com/927
-
gsc almost 7 years
-
user2948306 almost 7 yearsCorrection: I didn't see that message because I only ran
disable
. The message only appears onstop
(and it does appear if the service is already stopped). I can still empathize but I'm not sure what the best way to improve this experience would be. -
user253751 almost 7 years@jww Socket activation is one of my least unfavourite systemd features; it actually makes a lot of sense. (What doesn't make sense is for them to be classified separately to normal services)