I am disabling ipv6 via sysctl as follows:

echo net.ipv6.conf.all.disable_ipv6=1 > /etc/sysctl.d/ipv6.conf
sysctl -p /etc/sysctl.d/ipv6.conf

and I did run dracut to recreate initramfs as suggested in the following link https://access.redhat.com/solutions/2798411 and did everything as said

dracut -v -f

and this is the state of rpcbind.* process

systemctl list-unit-files | grep rpcbind
rpcbind.service                               indirect
rpcbind.socket                                enabled
rpcbind.target                                static

on reboot, I could see only rpcbind.socket has successfully started and rpcbind.service is in dead state

systemctl status rpcbind.socket
● rpcbind.socket - RPCbind Server Activation Socket
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.socket; enabled; vendor preset: enabled)
   Active: active (listening) since Thu 2018-02-15 11:25:09 GMT; 26min ago
   Listen: /var/run/rpcbind.sock (Stream)

Feb 15 11:25:09 seliics01979 systemd[1]: Listening on RPCbind Server Activation Socket.
Feb 15 11:25:09 seliics01979 systemd[1]: Starting RPCbind Server Activation Socket.

 systemctl status rpcbind.service
● rpcbind.service - RPC bind service
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: enabled)
   Active: inactive (dead)

I am puzzled to see that the rpcbind.service is still not starting up. However, manual start of rpcbind.service works fine. This happens in both VM and HP Gen9 hardware. Help required.

cat /usr/lib/systemd/system/rpcbind.service
Description=RPC bind service

ExecStart=/sbin/rpcbind -w $RPCBIND_ARGS


cat /usr/lib/systemd/system/rpcbind.target

Description=RPC Port Mapper

cat /usr/lib/systemd/system/rpcbind.socket
Description=RPCbind Server Activation Socket


  • Start the command by hand to see if it gives a more informative error; I also had problems with xinetd, snmpd and postfix (in Debian) – Rui F Ribeiro Feb 15 '18 at 12:02
  • 1
    Manual start of rpcbind.service is successful, but not persisting across reboot – Ibrahim Quraish Feb 15 '18 at 12:14

I solved this by removing the ::1 localhost address from /etc/hosts. It seems somehow this also triggers the behavior

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.