Bug 167578 - rpc.rstatd crashes on RHEL 3 update 5, empty disk_io value
Summary: rpc.rstatd crashes on RHEL 3 update 5, empty disk_io value
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-05 20:43 UTC by Natalia Watanabe
Modified: 2015-03-05 01:15 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-09-29 13:04:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Natalia Watanabe 2005-09-05 20:43:44 UTC
Hello,

I'm trying to use Mercury's LoadRunner to get performance measurements, but I 
can't get information about disks. I execute this steps:

1.- Start rpc.rstatd (service rstatd start)
2.- Use LoadRunner on a remote host but I got a error message (connection 
fails).
3.- rstatd daemon crashes

I had reviewed the /var/log/message file and found this line:

rpc.rstatd[9085]: incompatible to /proc. Could not read disk_io: data

Checking /proc/stat file, I got that disk_io hasn't had a value

disk_io:

I want to know how to resolve this problem or know if exist another program 
that replaces rpc.rstatd for Linux and works with LoadRunner

RedHat releases:

Red Hat Enterprise Linux ES release 3 (Taroon Update 5)
Red Hat Enterprise Linux AS release 3 (Taroon Update 5)

Hardware description:
- HP ProLiant DL360 G4p servers 
- 2 disk Ultra320, RAID 1

Thanks for your help.

Comment 1 Phil Knirsch 2005-09-06 13:38:00 UTC
Hm, according to you're info the /proc/stat didn't have any information for the
disk_io entry.

This of course would certainly make it impossible for rpc.rstatd to extract that
information and deliver it.

I'm checking with our kernel team why this might happen or if this might be a
know bug on those HP machines.

Read ya, Phil

Comment 2 Natalia Watanabe 2005-09-06 15:30:00 UTC
Hi Phil,

This is an example of /proc/stat

[root@server /]# cat /proc/stat
cpu  1143878 1076342 1361243 404057269 4657162 19160 163761
cpu0 343806 254680 380125 100938686 1156740 12 45663
cpu1 264828 289066 332337 101029662 1157497 8062 38116
cpu2 302497 242723 347946 101010290 1171233 2818 42261
cpu3 232747 289873 300835 101078631 1171692 8268 37721
page 311828 35995297
swap 6 0
intr 138191312 103148237 4 0 7 7 0 5 0 1 0 0 0 28 0 8279022 0 0 0 0 0 0 0 
573228 0 3989197 11100781 11100795 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
disk_io:
ctxt 771387202
btime 1124988801
processes 829906
procs_running 1
procs_blocked 0


Thanks

Comment 3 Phil Knirsch 2005-09-07 13:46:17 UTC
Hm, this really looks much more like a kernel problem as rstatd can't figure out
any of the disk statistics without a proper /proc/stat entry for disk_io.

I'm reassigning the bug to kernel so that team can look at it.

Read ya, Phil

Comment 4 Ernie Petrides 2005-09-08 01:11:43 UTC
Quoting from bug 144649 comment #2:

"This isn't a bug, its a limitation of the /proc/stat file and the data
structures which hold the information presented in it.  Due to ABI compatibility
issues, it is impossible in the RHEL3 series to add any stats to
/proc/partitions for devices with block major > 16.  Instead, /proc/partitions
has all the current information in /proc/stat (only in a slightly different
format), and includes the missing devices."

Phil, if you think it's reasonable to rework rpc.rstatd to use /proc/partitions,
then please reassign this BZ to that component.  Otherwise, please close this BZ
as WONTFIX.

Thanks in advance.


Comment 5 Phil Knirsch 2005-09-29 13:04:10 UTC
It would mean a fairly drastic change in the backend parsing and i'd rather no
do this for RHEL3.

Does this bug affect RHEL4 and newer FC releases, too, or is the kernel there
able to handle those devices properly?

Closing this bug as WONTFIX for now.

Read ya, Phil

Comment 6 Ernie Petrides 2005-09-29 23:45:14 UTC
Hi, Phil.  I don't know if the same limitation exists in the RHEL4 kernel.

Perhaps Jason or Tom could chime in.



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