Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 3994 - rpc.rstatd sends stale information
Summary: rpc.rstatd sends stale information
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rusers
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-12 03:07 UTC by Jeremy Katz
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-08-26 17:29:31 UTC

Attachments (Terms of Use)

Description Jeremy Katz 1999-07-12 03:07:51 UTC
Running rup on computers on the local network retrieves
out-of-date information from the rpc.rstatd process.  If you
then immediately run rup again, you get the accurate

For example, the following is the output from two rup
commands run within 5 seconds or so of each other.

nebula$ rup
nebula	         up             9:16,  load average: 2.00
2.05 2.02
blackhole        up             9:24,  load average: 1.00
1.00 0.94

nebula$ rup
nebula           up            11:48,  load average: 2.00
2.03 2.00
blackhole        up            11:55,  load average: 1.00
1.00 0.95

From looking at the strace output of the rpc.rstatd daemon,
it appears that rpc.rstatd sits in a select() syscall.  When
the rpc request comes in, it wakes up and starts receiving
SIGALRM from itself.  This causes the process to read the
information from /proc approximately 50 times.  Sending
another rpc request during this window gives the basically
correct values, though it still reports a cached value, the
value was just cached recently enough to be correct.  After
the ~50 reads of /proc, rpc.rstatd sits in a select() again.
This is a snippet of the strace output, starting at the
initial select and going through the first SIGALRM

select(1024, [5], NULL, NULL, NULL)     = 1 (in [5])
recvfrom(5, "\tNT3\0\0\0\0\0\0\0\2\0\1\206\241"..., 8800, 0,
, sin_port=htons(1168), sin_addr=inet_addr("")},
[16]) = 88
gettimeofday({931062870, 609484}, NULL) = 0
lseek(3, 0, SEEK_SET)                   = 0
read(3, "166174.45 154.57\n", 1023)     = 17
lseek(6, 0, SEEK_SET)                   = 0
read(6, "2.00 2.01 2.05 3/98 13504\n", 1023) = 26
open("/proc/stat", O_RDONLY)            = 8
read(8, "cpu  1553575 30222254 1426256 32"..., 1023) = 799
close(8)                                = 0
SYS_175(0, 0xbffff6d0, 0xbffff650, 0x8, 0) = 0
SYS_174(0x11, 0, 0xbffff454, 0x8, 0x11) = 0
SYS_175(0x2, 0xbffff650, 0, 0x8, 0x2)   = 0
nanosleep(0xbffff5bc, 0xbffff5bc, 0x4010f1b4, 0xbffff5bc,
0xbffff6d0) = 0
SYS_174(0xe, 0xbffff56c, 0xbffff4e0, 0x8, 0xe) = 0
alarm(1)                                = 0
sendto(5, "\tNT3\0\0\0\1\0\0\0\0\0\0\0\0\0\0"..., 128, 0,
{sin_family=AF_INET, s
in_port=htons(1168), sin_addr=inet_addr("")}, 16)
= 128
select(1024, [5], NULL, NULL, NULL)     = ? ERESTARTNOHAND
(To be restarted)
--- SIGALRM (Alarm clock) ---

This bug may exist in earlier versions of RHL, but I am
unsure as I don't have any machines running older versions
around to test with.  Another possibility may be in the
semantics of rpc.rstatd; most Unices run rpc.rstatd from
inetd rather than as a stand-alone daemon as is done in RHL.

Comment 1 Jeff Johnson 1999-08-26 17:29:59 UTC
Fixed in rusers-0.15-1.

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