I had a look at this issue, and the underlying problem seem to be that rpcbind do not notice that rpc.statd was stopped, and believe the port it request is occupied by another already running process when it try to register its port when it start again. The 'status' RPC service stay in the list even after rpc.statd is stopped.
I was able to work around the problem by wiping the status of rpcbind like this: service rpcbind stop ; rm /run/rpcbind/* ; service rpcbind stop But this should only be done if it is safe to restart all the RPC services, as rpcbind will forget about all of them. Check the output of 'rpcinfo -p' before and after to see which services need to be restarted and registered again with rpcbind. I have no idea why rpc.statd failed to tell rpcbind that its service was no longer active, and no idea how the changes in libtirpc since 0.2.2-5 could cause this. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
