Date: Thu, 20 May 2004 16:43:06 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Marius Strobl <marius@alchemy.franken.de>, Kris Kennaway <kris@obsecurity.org> Cc: sparc64@freebsd.org Subject: Re: 32-bit time in <utmp.h> (Re: cvs commit: ports/net/pppd23...) Message-ID: <p06020401bcd2b1bdeaa9@[128.113.24.47]> In-Reply-To: <20040428224819.A86269@newtrinity.zeist.de> References: <200404281956.i3SJuZxU033263@repoman.freebsd.org> <20040428202237.GA49702@xor.obsecurity.org> <20040428224819.A86269@newtrinity.zeist.de>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:48 PM +0200 4/28/04, Marius Strobl wrote:
>On Wed, Apr 28, 2004 at 01:22:37PM -0700, Kris Kennaway wrote:
>>
> > I wonder if this 32-bitness is related to the accounting
> > problems noticed on sparc64 since the 64-bit time_t
> > changeover:
> >
>> struct lastlog {
>> int32_t ll_time;
>> char ll_line[UT_LINESIZE];
>> char ll_host[UT_HOSTSIZE];
>> };
>>
>> struct utmp {
>> char ut_line[UT_LINESIZE];
>> char ut_name[UT_NAMESIZE];
>> char ut_host[UT_HOSTSIZE];
>> int32_t ut_time;
>> };
>>
>
>Like I said before, this isn't a sparc64 specific problem, I also
>see it on my -current i386 boxes:
>
>tristan# uname -a
>FreeBSD tristan.franken.de 5.2-CURRENT FreeBSD 5.2-CURRENT #0: Wed
>Apr 28 22:11:03 CEST 2004
>root@tristan.franken.de:/usr/src/sys/i386/compile/tristan i386
>tristan# /etc/periodic/monthly/200.accounting
>
>Doing login accounting:
>(Skipped 709 of 739 records due to invalid time values)
>(Changed 3 of 739 records to have a more likely time value)
> root -65080.69
> marius -136664.62
> total -201745.32
>
>I think it's connected to SCHED_ULE, but haven't checked that
>closely, yet.
It isn't documented in the man page, but you could compile
/usr/src/usr.sbin/ac with CFLAGS+=-DDEBUG
and then run: ac -D -p -w /var/log/wtmp
to see a lot more detail about each run. I have the makefile
compile `ac' with DEBUG for sparc64. I did not do that for the
other architectures because I thought this problem was specific to
64-bit time_t. (in fact, I'm pretty sure that no one complained
about this problem on sparc64 until we went to 64-bTT).
I still haven't seen this error on my own systems. I'm surprised
that you see such a high percentage of suspect records. I'm also
surprised that you still ended up with such bogus results even
after `ac' has skipped over all the suspect records!
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020401bcd2b1bdeaa9>