Bug 732327 - rusers and rup not responding
Summary: rusers and rup not responding
Keywords:
Status: CLOSED DUPLICATE of bug 781880
Alias: None
Product: Fedora
Classification: Fedora
Component: rusers
Version: 16
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Honza Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-22 02:18 UTC by Elliott Forney
Modified: 2012-06-26 14:48 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-06-26 14:48:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
output of systemctl, rup and rusers (2.71 KB, application/octet-stream)
2011-08-22 02:18 UTC, Elliott Forney
no flags Details

Description Elliott Forney 2011-08-22 02:18:07 UTC
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.

Comment 1 Honza Horak 2011-09-20 07:39:15 UTC
Please mind, that rstatd service has to be started to be able to use rup. Does it work now?

Comment 2 Elliott Forney 2011-09-20 08:26:55 UTC
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?

Comment 3 Honza Horak 2011-09-20 08:49:44 UTC
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")?

Comment 4 Elliott Forney 2011-09-20 15:31:08 UTC
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

Comment 5 Honza Horak 2011-09-23 14:35:35 UTC
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?

Comment 6 Elliott Forney 2011-09-26 06:28:27 UTC
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.

Comment 7 Elliott Forney 2011-09-26 06:30:50 UTC
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.

Comment 8 Elliott Forney 2011-09-26 06:34:28 UTC
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.

Comment 9 Honza Horak 2011-09-26 09:07:45 UTC
(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?

Comment 10 Honza Horak 2011-09-26 09:08:31 UTC
(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.

Comment 11 Elliott Forney 2011-09-26 20:55:54 UTC
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.

Comment 12 Elliott Forney 2011-09-26 21:13:03 UTC
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?

Comment 13 Honza Horak 2011-09-27 10:53:43 UTC
(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.

Comment 14 Elliott Forney 2011-09-27 16:54:57 UTC
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.

Comment 15 Honza Horak 2012-01-31 15:48:15 UTC
Any updates here? Do you still encounter the issue?

Comment 16 Elliott Forney 2012-04-05 19:54:41 UTC
I still encounter this problem with Fedora 16.  "rup machinename" works fine but the broadcast functionality, i.e. "rup", still does not work.

Comment 17 Honza Horak 2012-04-25 10:21:54 UTC
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

Comment 18 Honza Horak 2012-04-25 11:19:31 UTC
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

Comment 20 Honza Horak 2012-06-26 14:48:54 UTC
Marking as duplicate of bug #781880, as per comment #19.

*** This bug has been marked as a duplicate of bug 781880 ***


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