Bug 149201

Summary: rpc.statd crashes on startup
Product: [Fedora] Fedora Reporter: Paul Jakma <paul+rhbugz>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Ben Levenson <benl>
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: mattdm, oliva, pza
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-06 18:47:15 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
strace of statd crashing at startup none

Description Paul Jakma 2005-02-20 19:57:06 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 Galeon/1.3.19

Description of problem:
rpc.statd crashes on startup, apparently while reading information from a netlink socket. This problem occurs with nfs-utils_1.0.6-52 and nfs-utils_1.0.6-53, but doesnt occur with nfs-utils_1.0.6-44.

I will attach a strace of rpc.statd -F. ltrace doesnt show anything interesting and unfortunately the -debuginfo rpm for -52 was empty (I didnt find the -53 debuginfo rpm).

output of "ip address" command:

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet brd scope host lo
    inet scope global lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0e:0c:59:df:20 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
    inet brd scope global eth0
    inet6 2001:770:105:1:260:97ff:fe54:1ec9/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:cff:fe59:df20/64 scope link 
       valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit brd
4: sit1@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue 
    link/sit peer
    inet6 2001:770:100:8::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::d411:3731/128 scope link 
       valid_lft forever preferred_lft forever
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc htb qlen 3
    inet peer scope global ppp0

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. upgrade to -52 (possibly with the above ip configuration)
2. try and start rpc.statd
3. observe it segv early on

Actual Results:  rpc.statd SEGVs. NFS clients behave strangely.

Expected Results:  rpc.statd should start without crashing.

Additional info:
Comment 1 Paul Jakma 2005-02-20 20:00:14 EST
Created attachment 111245 [details]
strace of statd crashing at startup

This shows statd crashing after recvmsg().
Comment 2 Paul Jakma 2005-02-20 20:06:13 EST
Reading interface information seems to be a regular cause of bugs in a variety
of packages (i've reported bugs in things like krb5 before, where it crashed
reading interface information), it'd be a really nice nice idea to try
standardise this interface state into a library...
Comment 3 Peter Bieringer 2005-03-01 14:23:20 EST
Same happen to me (also an IPv6 enabled box), it's a show stopper for running
KDE on a remote host with a mounted home directory.
Comment 4 Peter Bieringer 2005-03-01 14:25:56 EST
Looks like no one cares about this bug, so pls. can one change the priority to
"high"? The crash of rpc.statd prevent NFS client/server from proper file locking.
Comment 5 Paul Jakma 2005-03-02 07:35:58 EST
I'm changing this to high.

This bug is high impact to clients of a server affected, locking doesn't work,
GNOME desktops hosted out of NFS mounted /home dirs become painful to use. I've
had to downgrade nfs-utils to -44 and pin it to that version in my apt preferences.
Comment 8 Phil Anderson 2005-03-05 20:53:54 EST
I can confirm this bug, and it is causing havoc for me.  I'm reverting to the
old version.
Comment 9 Phil Anderson 2005-03-16 17:55:54 EST
Has anyone had the chance to try nfs-utils 1.0.7-1 from development?  I'll give
it a try later today to see if it fixes the problem.
Comment 10 Peter Bieringer 2005-03-17 02:36:46 EST
I've updated here and restarted nfs. rpc.statd stays alive, so this version works.

To @redhat -> pls. push that version to FC3 updates.
Comment 11 Phil Anderson 2005-03-21 18:02:37 EST
I too have updated to 1.0.7-1 and it doesn't crash on startup.  I've done some
basic testing on it, and it appears to work fine.  I agree with comment 10 in
that this really needs to be put through as an FC3 update.
Comment 12 Peter Bieringer 2005-03-29 16:03:21 EST
Strange, after a reboot this issue comes up again:

03/29/2005 22:53:22 rpc.statd[15146]: Version 1.0.7 Starting
03/29/2005 22:53:22 rpc.statd[15146]: Flags: No-Daemon Log-STDERR
03/29/2005 22:53:22 rpc.statd[15146]: New state: 655
Segmentation fault

bind(8, {sa_family=AF_INET, sin_port=htons(921), sin_addr=inet_addr("")},
16) = -1 EACCES (Permission denied)
ioctl(8, FIONBIO, [1])                  = 0
setsockopt(8, SOL_IP, IP_RECVERR, [1], 4) = 0
sendto(8, "#\325?`\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\1\0\0"..., 56, 0,
{sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("")}, 16) = 56
poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
recvfrom(8, "#\325?`\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1"..., 400,
0, {sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("")},
[16]) = 28
close(8)                                = 0
time([1112129621])                      = 1112129621
time([1112129621])                      = 1112129621
socket(PF_NETLINK, SOCK_RAW, 0)         = 8
bind(8, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(8, {sa_family=AF_NETLINK, pid=15153, groups=00000000}, [12]) = 0
time(NULL)                              = 1112129621
sendto(8, "\24\0\0\0\22\0\1\3U\300IB\0\0\0\0\0\0\0\0", 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(8, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
4096}], msg_controllen=0, msg_flags=0}, 0) = 3012
recvmsg(8, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
sendto(8, "\24\0\0\0\26\0\1\3V\300IB\0\0\0\0\0\0\0\0", 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
recvmsg(8, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
4096}], msg_controllen=0, msg_flags=0}, 0) = 536
recvmsg(8, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
4096}], msg_controllen=0, msg_flags=0}, 0) = 1024
recvmsg(8, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
close(8)                                = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I have nothing special changed on the system.
Comment 13 Steve Dickson 2005-03-30 14:01:09 EST
This appears to be the same problem at in bz151828.
Please down the the nfs-utils in http://people.redhat.com/steved/bz151828/
to see if they solve the problem.
Comment 14 Phil Anderson 2005-03-31 20:44:45 EST
1.0.6-55 starts up for me.  However, so did 1.0.7-1 for a bit (comment 11), then
it stopped working (I can't work out why).  I'll post any progress.
Comment 15 Peter Bieringer 2005-04-01 01:49:41 EST
1.0.6-55 starts for me, too.
Comment 16 Paul Jakma 2005-04-01 07:46:40 EST
I've installed 1.0.6-55 here, and it does appear to have started up without
Comment 17 Steve Dickson 2005-04-01 07:55:16 EST
thanks for all the help!!!

*** This bug has been marked as a duplicate of 151828 ***
Comment 18 Alexandre Oliva 2005-07-27 09:44:43 EDT
Not quite a dupe if it doesn't apply to the same OS/release.  We'll never get an
update for FC3 if there isn't at least an open bugzilla that applies to FC3 on
this, are we?
Comment 19 Steve Dickson 2005-07-27 11:19:06 EDT
The nfs-utils is fixed in FC4 which should work just fine on an FC3 machine.
Comment 20 Alexandre Oliva 2005-07-27 12:42:28 EDT
Then it should be pretty easy to address the problem for FC3 by releasing an
update for it, no?
Comment 21 Matthew Miller 2006-07-10 19:14:52 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 22 petrosyan 2008-02-06 18:47:15 EST
Fedora Core 3 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release please reopen this bug and assign it to the corresponding
Fedora version.