Bug 3994 - rpc.rstatd sends stale information
rpc.rstatd sends stale information
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rusers (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-11 23:07 EDT by Jeremy Katz
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-26 13:29:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 1999-07-11 23:07:51 EDT
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
information.

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_family=AF_INET
, sin_port=htons(1168), sin_addr=inet_addr("192.168.0.7")},
[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("192.168.0.7")}, 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 13:29:59 EDT
Fixed in rusers-0.15-1.

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