Bug 149201 - rpc.statd crashes on startup
Summary: rpc.statd crashes on startup
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-21 00:57 UTC by Paul Jakma
Modified: 2008-02-06 23:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-06 23:47:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of statd crashing at startup (29.73 KB, text/plain)
2005-02-21 01:00 UTC, Paul Jakma
no flags Details

Description Paul Jakma 2005-02-21 00:57:06 UTC
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-21 01:00:14 UTC
Created attachment 111245 [details]
strace of statd crashing at startup

This shows statd crashing after recvmsg().

Comment 2 Paul Jakma 2005-02-21 01:06:13 UTC
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 19:23:20 UTC
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 19:25:56 UTC
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 12:35:58 UTC
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-06 01:53:54 UTC
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 22:55:54 UTC
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 07:36:46 UTC
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 23:02:37 UTC
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 21:03:21 UTC
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 19:01:09 UTC
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-04-01 01:44:45 UTC
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 06:49:41 UTC
1.0.6-55 starts for me, too.

Comment 16 Paul Jakma 2005-04-01 12:46:40 UTC
I've installed 1.0.6-55 here, and it does appear to have started up without

Comment 17 Steve Dickson 2005-04-01 12:55:16 UTC
thanks for all the help!!!

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

Comment 18 Alexandre Oliva 2005-07-27 13:44:43 UTC
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 15:19:06 UTC
The nfs-utils is fixed in FC4 which should work just fine on an FC3 machine.

Comment 20 Alexandre Oliva 2005-07-27 16:42:28 UTC
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 23:14:52 UTC
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 23:47:15 UTC
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.

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