Bug 15832

Summary:	the w commands can show a bad result on the idle time
Product:	Base System	Reporter:	admin <admin>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description admin 2000-01-02 02:40:00 UTC

the w commands show a bad idle time ;)

fire# w
 9:37PM  up 40 days, 4 hrs, 2 users, load averages: 0.00, 0.00, 0.00
USER             TTY      FROM              LOGIN@  IDLE WHAT
root             v1       -                 8:37PM 228days -csh (csh)
root             p0       poste1            8:58PM     - w
fire# uptime
 9:37PM  up 40 days, 4 hrs, 2 users, load averages: 0.00, 0.00, 0.00
fire#          
fire# date
Sat Jan  1 21:38:40 EST 2000
fire#

Fix: 

;P
How-To-Repeat: im not sure but i think it's year2000 .

Comment 1 Jens Schweikhardt 2000-01-07 09:32:30 UTC

I have discovered the same and tried to investigate
a little (last night at 11pm... so beware).

The bogus idle time happens on my 3.2-RELEASE system
when I (eg) start a new xterm which needs a new pty,
say /dev/ttypq. If I do not type anything in the new
xterm's shell, /usr/bin/w uses /dev/ttypq's st_atimesec
(as displayed by ls -u /dev/ttypq)
as the last "active" point in time which can well be
beyond the uptime.

I'm not sure if this is w's fault or if the st_atimesec
of the pty is not properly updated when the pty is used
(opened?). As soon as I run some command in that pty,
everything is okay.

-- 

Regards,

	Jens
-- 
Jens Schweikhardt  http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

Comment 2 kbyanc 2000-01-07 17:28:56 UTC

> # 
> #   I don't suppose you have the noatime option set for the root filesystem?
> 
> Good point, I'll verify this as soon as I get home.
> 
> But why is it that the st_atime seems to be changed when I type something?
> In-core copy of the respective struct stat?
> 

  Good point. Scratch that. If the file system was mounted with noatime
then it shouldn't be updated at all. The correct answer is that stat(2)
documents that the atime field is only updated by the mknod(2), utimes(2)
and read(2) system calls. Open(2) doesn't touch atime.
  What you are seeing is documented behaviour, even if it isn't intuitive.

  Kelly

--
Kelly Yancey  -  kbyanc@posi.net  -  Richmond, VA
Analyst / E-business Development, Bell Industries  http://www.bellind.com/
Maintainer, BSD Driver Database       http://www.posi.net/freebsd/drivers/
Coordinator, Team FreeBSD        http://www.posi.net/freebsd/Team-FreeBSD/

Comment 3 Doug White freebsd_committer

2000-05-12 00:01:02 UTC

State Changed
From-To: open->closed

Determined to be 'documented' behavior... unless someone can demonstrate it 
on 3.4 or later ...