Hide Forgot
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): rusers-0.17-31.1 How reproducible: Always 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
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