Minor problem with 64bTT: monthly accounting figures
Peter Wemm
peter at wemm.org
Mon Apr 19 14:09:48 PDT 2004
On Monday 01 March 2004 11:03 am, Garance A Drosihn wrote:
> At 4:03 PM +0100 3/1/04, Maxime Henrion wrote:
> >Tillman Hodgson wrote:
> >> Look a little odd this month:
> >>
> >> Subject: caliban.rospa.ca monthly run output
> >>
> >> Doing login accounting:
> >> root 0.84
> >> total -298848.27
> >> toor -298849.12
> >>
> > > -- End of monthly output --
>
> This would be from the output of the 'ac' command. I tried
> this on my 64-bTT machine, and it seemed to be working OK.
>
> >This is probably because the time is stored as a 32-bits integer
> >in /var/run/utmp and /var/log/wtmp.
>
> If the time-value is defined as a fixed 32-bit integer (instead
> of being time_t), then the records themselves should be fine. The
> records (as written) won't be changing in size due to this change.
>
> So, if there is a bug here then it'll probably be in the 'ac'
> program. That's my guess, at least. We can look into that some
> more, but don't need to address it right away.
Just fyi, ac does things like this:
time_t ut_timecopy;
ut_timecopy = _time32_to_time(event_up->ut_time);
strlcpy(str_result, ctime(&ut_timecopy), sizeof(str_result));
However, there is also a big scary comment that says:
* With sparc64 using 64-bit time_t's, there is some system
* routine which sets ut_time==0 (the high-order word of a
* 64-bit time) instead of a 32-bit time value.
It sounds like something clobbers ut_time..
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
More information about the freebsd-sparc64
mailing list