From nobody@FreeBSD.ORG  Sat Jan  1 18:39:34 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 9FB8315052; Sat,  1 Jan 2000 18:39:34 -0800 (PST)
Message-Id: <20000102023934.9FB8315052@hub.freebsd.org>
Date: Sat,  1 Jan 2000 18:39:34 -0800 (PST)
From: admin@ewan.qc.ca
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: the w commands can show a bad result on the idle time
X-Send-Pr-Version: www-1.0

>Number:         15832
>Category:       bin
>Synopsis:       the w commands can show a bad result on the idle time
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jan  1 18:40:00 PST 2000
>Closed-Date:    Thu May 11 16:01:02 PDT 2000
>Last-Modified:  Thu May 11 16:01:51 PDT 2000
>Originator:     Mathieu Nadeau
>Release:        3.2-release
>Organization:
Services Internet Mathnet
>Environment:
FreeBSD fire.mathnet.org 3.2-RELEASE FreeBSD 3.2-RELEASE #6: Sun Nov  7 12:50:56 EST 199
9     root@fire.mathnet.org:/usr/src/sys/compile/FIRE  i386            
>Description:
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#       
>How-To-Repeat:
im not sure but i think it's year2000 .
>Fix:
;P 

>Release-Note:
>Audit-Trail:

From: Jens Schweikhardt <schweikh@noc.dfn.de>
To: freebsd-gnats-submit@FreeBSD.org, admin@ewan.qc.ca
Cc:  
Subject: Re: bin/15832: the w commands can show a bad result on the idle time
Date: Fri, 07 Jan 2000 10:32:30 +0100

 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)
 

From: Kelly Yancey <kbyanc@posi.net>
To: Jens Schweikhardt <schweikh@noc.dfn.de>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/15832: the w commands can show a bad result on the idle time
Date: Fri, 7 Jan 2000 12:28:56 -0500 (EST)

 > # 
 > #   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/
 
 
State-Changed-From-To: open->closed 
State-Changed-By: dwhite 
State-Changed-When: Thu May 11 16:01:02 PDT 2000 
State-Changed-Why:  
Determined to be 'documented' behavior... unless someone can demonstrate it 
on 3.4 or later ...  
>Unformatted:
