Hide Forgot
Created attachment 519213 [details] output of systemctl, rup and rusers Description of problem: rpcbind and rusersd are running but rup and rusers do not respond. Version-Release number of selected component (if applicable): rpcbind-0.2.0-10.fc15.x86_64 rusers-0.17-62.fc15.x86_64 rusers-server-0.17-62.fc15.x86_64 How reproducible: Always. Steps to Reproduce: 1. Start rpcbind and rusersd 2. run rup or rusersd Actual results: No response. Expected results: Hosts running rusersd should respond. Additional info: Attachment shows configuration and output.
Please mind, that rstatd service has to be started to be able to use rup. Does it work now?
rstatd is running but rup and rusers still do not work: platte:~# systemctl status rstatd.service rstatd.service - LSB: start and stop rpc.rstatd Loaded: loaded (/etc/rc.d/init.d/rstatd) Active: active (running) since Tue, 13 Sep 2011 08:10:03 -0600; 6 days ago Main PID: 1123 (rpc.rstatd) CGroup: name=systemd:/system/rstatd.service └ 1123 rpc.rstatd platte:~# ps -elf | grep rstatd 5 S root 1123 1 0 80 0 - 2094 poll_s Sep13 ? 00:00:00 rpc.rstatd platte:~# netstat -nap | grep rstatd udp 0 0 0.0.0.0:878 0.0.0.0:* 1123/rpc.rstatd iptables is also turned off. It seems to work fine for me in Fedora 14 but not in Fedora 15. Can anyone else verify that it does/doesn't work in Fedora 15?
What about if you run rup only on the specified host? $ rup secondmachinehostname Does rup print some error? Does "rpcinfo -p secondmachinehostname" print correct services registered? program vers proto port service 100001 3 udp 816 rstatd 100001 2 udp 816 rstatd 100001 1 udp 816 rstatd 100002 3 udp 820 rusersd 100002 2 udp 820 rusersd (In reply to comment #2) > iptables is also turned off. Is iptables turned off on both machines (even on the machine where you run "rup")?
Oh, interestingly, I if I run $ rup secondmachinehostname it works fine, no error. If, however I simply run $ rup I get no replies. It looks like the problem is only with the broadcast functionality. Yes, iptables is off on all of our Fedora clients. rpcinfo does show rstatd and rusersd registered: corn:~$ rpcinfo -p cabbage program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 43203 status 100024 1 tcp 49685 status 100001 3 udp 847 rstatd 100001 2 udp 847 rstatd 100001 1 udp 847 rstatd 100002 3 udp 850 rusersd 100002 2 udp 850 rusersd 100007 2 udp 911 ypbind 100007 1 udp 911 ypbind 100007 2 tcp 914 ypbind 100007 1 tcp 914 ypbind 100021 1 udp 32886 nlockmgr 100021 3 udp 32886 nlockmgr 100021 4 udp 32886 nlockmgr 100021 1 tcp 43329 nlockmgr 100021 3 tcp 43329 nlockmgr 100021 4 tcp 43329 nlockmgr
This is weird. You can check what packages are sent in the network. There should be one broadcast packet from A -> network and B should reply to A with udp packet. Do you see both of these packages? Or the first only? And what about syslog, is there something?
On the machine issuing the broadcast rup request (from Fedora 15) I actually see six UDP packets go out at about one second intervals: cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43177 > 129.82.47.255.sunrpc: UDP On a Fedora 14 machine on the network I see six incoming UDP packets and six replies: cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP cabbage.cs.colostate.edu.50930 > 129.82.47.255.sunrpc: UDP horde-1.cs.colostate.edu.885 > cabbage.cs.colostate.edu.50930: UDP On a Fedora 15 machine on the network I see six incoming UDP packets and no replies: cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP cabbage.cs.colostate.edu.43042 > 129.82.47.255.sunrpc: UDP It looks like it is just not responding.
I tried this on my home network too and it seems to do the same thing. I'm pretty sure I haven't misconfigured anything... I can't think of anything else that would prevent it from working.
This is all I see in /var/log/messages. Everything at boot, nothing at the moment that I hit rup on either machine. rpc.statd[960]: Version 1.2.4 starting rpc.statd[960]: Flags: TI-RPC kernel: [ 32.041856] RPC: Registered named UNIX socket transport module. kernel: [ 32.041859] RPC: Registered udp transport module. kernel: [ 32.041860] RPC: Registered tcp transport module. kernel: [ 32.041862] RPC: Registered tcp NFSv4.1 backchannel transport module. modprobe: FATAL: Module sunrpc already in kernel.
(In reply to comment #8) > rpc.statd[960]: Version 1.2.4 starting > rpc.statd[960]: Flags: TI-RPC This is part of nfs-utils package and shouldn't influence rstatd at all. > modprobe: FATAL: Module sunrpc already in kernel. I don't understand what this means, but maybe something inside sunrpc requests handling can be somehow broken. Can you try to fix this, e.g. by re-installing kernel?
(In reply to comment #9) > I don't understand what this means, but maybe something inside sunrpc requests > handling can be somehow broken. Can you try to fix this, e.g. by re-installing > kernel? Maybe glibc can be updated too.
The modprobe error comes from /etc/modprobe.d/dist.conf: # cd /etc/modprobe.d/ # grep rpc dist.conf install sunrpc /sbin/modprobe --first-time --ignore-install sunrpc && { /bin/mount -t rpc_pipefs sunrpc /var/lib/nfs/rpc_pipefs > /dev/null 2>&1 || :; } remove sunrpc { /bin/umount /var/lib/nfs/rpc_pipefs > /dev/null 2>&1 || :; } ; /sbin/modprobe -r --ignore-remove sunrpc alias rpc_pipefs sunrpc alias rpc_svc_gss_pipefs sunrpc # /sbin/modprobe --first-time --ignore-install sunrpc FATAL: Module sunrpc already in kernel. Should be fixed but I doubt it is the cause of this problem.
I am running the latest kernel and glibc straight from the Fedora repos: kernel-2.6.40.4-5.fc15.x86_64 glibc-2.14-5.x86_64 The problem has also persisted across at least one kernel update. Can anyone else reproduce this problem?
(In reply to comment #12) > I am running the latest kernel and glibc straight from the Fedora repos: > > kernel-2.6.40.4-5.fc15.x86_64 > glibc-2.14-5.x86_64 It work without problem by me with these builds.
The "FATAL: Module sunrpc already in kernel." error goes away if I comment out the "install sunrpc..." lines in /etc/modprobe.d/dist.conf but rusers still doesn't work for me. I am quite perplexed by this. I have tried this on several machines on several different networks (hundreds of machines at one location) and I can't seem to get it to work anywhere. It works when specifying the host name explicitly but the broadcast functionality doesn't work. I suppose the next step for me will be to try a fresh, default install and see if it works there.
Any updates here? Do you still encounter the issue?
I still encounter this problem with Fedora 16. "rup machinename" works fine but the broadcast functionality, i.e. "rup", still does not work.
I suspected this bug could be related to bug #781880, but it works for me with libtirpc-0.2.2-1.1.fc16.x86_64. Anyway, what build of libtirpc do you use on your machines (those which you're running rstatd on and rup as well)? Actually, you can simply pass output of the following command run on both machines: $ rpm -q libtirpc rpcbind kernel rusers rusers-server glibc
Thinking about bug #781880 a bit more, the problematic changes introducing that bug were pushed to F15 in June 2011. You reported this bug in August 2011. I just wonder if the version prior these changes worked correctly for you. Can you, please, try libtirpc-0.2.1-6.fc15 available for example in [1]? However, please, be aware that when installing that particular build, you should downgrade rpcbind as well, the reason is in [2]. The older compatible rpcbind-0.2.0-11.fc16 is available in [3]. [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=207437 [2] https://bugzilla.redhat.com/show_bug.cgi?id=781880#c15 [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=234342
I confirm that the patch attachment #579877 [details] from the libtirpc bug #781880 fixes all problems with (rpcbind-mediated) RPC broadcasts. These include rup and rusers bugs. I have made some fixed packages available here: http://rpm.fifi.org/f17-fifi/i386/libtirpc-0.2.2-2.1.0.0.1.fif17.i686.rpm http://rpm.fifi.org/f17-fifi/i386/libtirpc-devel-0.2.2-2.1.0.0.1.fif17.i686.rpm http://rpm.fifi.org/f17-fifi/x86_64/libtirpc-0.2.2-2.1.0.0.1.fif17.x86_64.rpm http://rpm.fifi.org/f17-fifi/x86_64/libtirpc-devel-0.2.2-2.1.0.0.1.fif17.x86_64.rpm Phil.
Marking as duplicate of bug #781880, as per comment #19. *** This bug has been marked as a duplicate of bug 781880 ***