Bug 130286 - rpc.rstatd reports nonsensical uptime on s390x
Summary: rpc.rstatd reports nonsensical uptime on s390x
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rusers
Version: 3.0
Hardware: s390x
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-18 20:07 UTC by Will Woods
Modified: 2015-03-05 01:14 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2005-09-07 13:39:24 UTC

Attachments (Terms of Use)

Description Will Woods 2004-08-18 20:07:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040803 Firefox/0.9.3

Description of problem:
when 'rup' is run to check the uptime on a remote s390x machine, the
uptime value returned is a negative number.

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

How reproducible:

Steps to Reproduce:
1. service rstatd start 
2. rup localhost

Actual Results:  uptime is sane, but rup isn't:
(kryten is an s390x machine)
[root@kryten root]# uptime; rup localhost
 12:01:04  up 16 days,  5:08,  7 users,  load average: 0.00, 0.00, 0.00
localhost                up 37077 days, 19:36,    load average: 0.00
0.00 0.00

when rup is run against it from another machine:
[root@bender root]# rup kryten.z900.redhat.com
kryten.z900.redhat.com   up           -18190732 mins,  load average:
0.00 0.00 0.00

Expected Results:  
(lister is a 31-bit machine in the same z900)
[root@lister root]# uptime ; rup localhost
 12:05:57  up 16 days,  5:13, 10 users,  load average: 0.20, 0.05, 0.02
localhost                up  16 days,  5:13,    load average: 0.20
0.05 0.02

[root@bender root]# rup lister.z900.redhat.com
lister.z900.redhat.com   up  16 days,  5:13,    load average: 0.20
0.05 0.02

Comment 1 Phil Knirsch 2004-10-20 14:40:48 UTC
Reproduced here. Looking into it.

Read ya, Phil

Comment 2 Phil Knirsch 2005-09-07 13:39:24 UTC
Found the bug. Problem is that rstatd assumed that struct timeval had 2 4 byte
integers as it defined it's onw timeval structure for transport like that.

gettimeofday() though can only fill in a real host struct timeval which
unfortunately has 2 8 byte integers. It worked on little endian 64bit machines
as rup only used the first field, namely tv_sec, which got filled in conrrectly
in little endian. On big endian 64bit machines the first 4 bytes would be 0
though (as we haven't reached the year where the seconds will overflow yet).

Fix is to actually use the proper host struct timeval for the call to
gettimeofday() and then fill in the transport structure.

Fix will be in next rusers package in development.

Read ya, Phil

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