Red Hat Bugzilla – Bug 130286
rpc.rstatd reports nonsensical uptime on s390x
Last modified: 2015-03-04 20:14:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
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):
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
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
(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
[root@bender root]# rup lister.z900.redhat.com
lister.z900.redhat.com up 16 days, 5:13, load average: 0.20
Reproduced here. Looking into it.
Read ya, Phil
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