Subject: kern/37126: Bogus tty idle times
To: None <email@example.com, firstname.lastname@example.org,>
From: None <email@example.com>
Date: 10/13/2007 22:45:01
>Synopsis: Bogus tty idle times
>Arrival-Date: Sat Oct 13 22:45:00 +0000 2007
>Originator: David A. Holland <firstname.lastname@example.org>
>Release: NetBSD 2.99.something through 4.99.31 (20071005)
System: NetBSD tanaqui 4.99.31 NetBSD 4.99.31 (TANAQUI) #19: Tue Sep 11 19:46:35 EDT 2007 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386
Tty idle times reported by w(1), finger(1), and other tools are
frequently 0 when they should not be. This results in tty messages
going to the wrong tty, and also gives false information about whether
users are around or not - this is particularly irritating on a
multiuser machine where the users know each other or work together or
This started happening sometime after 2.0 and before 3.0; I've only
just finally gotten around to digging out exactly what's wrong.
The problem is that the code for deferring atime (and mtime, but it's
atime that matters here) updates only sets a flag saying that atime
needs to be updated; it doesn't save the time to apply. When the
update is flushed later, the current time is (generally) used.
When a tty is idle, nothing much is going to cause a pending atime
update to be applied until someone goes to stat it, as is done by w(1)
for the purpose of computing idle times. The stat call flushes the
times; then the current time is applied, and poof, the tty comes up
with a zero idle time, even if the person using it went home for the
weekend hours or days previously.
Log in a bunch of times, idle for a while, and use w. It's not always
easy to trigger the problem on demand, but it happens pretty regularly
if you do this a lot.
Deferred time updates should really store the time to be applied.
This could be done by sticking the time in memory somewhere, or by
changing the way the feature works so the time is applied to the inode
but not written to disk, or possibly other ways. None of these
alternatives is exactly trivial, so someone (else) needs to decide
what approach to take.
It might also be useful to at the same time reduce the number of
places where the time updates are flushed to disk; for example, if one
has the time values available there's no real reason to flush on stat.