Bug 25777

Comment 1 Jens Schweikhardt 2002-08-17 12:08:46 UTC

State Changed
From-To: open->feedback

It is not clear if atime needs to be updated upon exec'ing a file. 
Here's what the current IEEE Std 1003.1-2001 has to say: 

"File Times Update 

Each file has three distinct associated time values: st_atime, st_mtime, 
and st_ctime. The st_atime field is associated with the times that the 
file data is accessed; st_mtime is associated with the times that the 
file data is modified; and st_ctime is associated with the times that 
the file status is changed. These values are returned in the file 
characteristics structure, as described in <sys/stat.h> . 

Each function or utility in IEEE Std 1003.1-2001 that reads or writes 
^^^^^^^^^^^^^^^ 
data or changes file status indicates which of the appropriate 
time-related fields shall be "marked for update". If an implementation 
of such a function or utility marks for update a time-related field not 
specified by IEEE Std 1003.1-2001, this shall be documented, except that 
any changes caused by pathname resolution need not be documented. For 
the other functions or utilities in IEEE Std 1003.1-2001 (those that are 
not explicitly required to read or write file data or change file 
status, but that in some implementations happen to do so), the effect is 
unspecified. [...]" 

If we associate "reading" and "writing" with the rwx bits, then 
to execute you don't need to "read" a file. 

Bruce (bde), what's your view?

On Sat, 17 Aug 2002, Jens Schweikhardt wrote:

> State-Changed-Why:
> It is not clear if atime needs to be updated upon exec'ing a file.

Er, this is clear.

> Here's what the current IEEE Std 1003.1-2001 has to say:
>
> "File Times Update

Look in the section on exec:

9746              Upon successful completion, the exec functions shall mark for update the st_atime field of the file.
9747              If an exec function failed but was able to locate the process image file, whether the st_atime field is
9748              marked for update is unspecified. Should the exec function succeed, the process image file shall
9749              be considered to have been opened with open( ). The corresponding close( ) shall be considered
9750              to occur at a time after this open, but before process termination or successful completion of a
9751              subsequent call to one of the exec functions, posix_spawn( ), or posix_spawnp( ). The argv[ ] and

I tried to fix this many years ago, and fixed it enough to prevent
NIST PCTS (a test suite for POSIX.1-1990 + FIPS.mumble) from reporting
this bug, but dg didn't like the overheads for this and I didn't like
them either for nfs.  For ufs, the atime update is done using delayed
writes, so I think it was efficient enough unless lots of _different_
files are exec'ed.  I subsequently implemented lazy atime updates and
these make the problem for ufs even smaller.  The updates still have to
be done sometime so accessing lots of _different_ files still causes
lots of i/o.  For nfs, atime updates at least used to involve an nfs
transaction each.  The nfs attribute cache may help here.

Here is part of my old patch.  It depends on other patches for VOP_SETTATR()
and probably doesn't even compile now.

%%%
Index: kern_exec.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.180
diff -u -2 -r1.180 kern_exec.c
--- kern_exec.c	13 Aug 2002 06:55:28 -0000	1.180
+++ kern_exec.c	15 Aug 2002 14:07:51 -0000
@@ -547,4 +537,18 @@
 		pargs_drop(newargs);

+#if 0
+	if (!(ndp->ni_vp->v_mount->mnt_flag & MNT_NOATIME)) {
+		struct vattr vattr;
+
+		VATTR_NULL(&vattr);
+		vfs_timestamp(&vattr.va_atime);
+		vattr.va_vaflags |= VA_EXECVE_ATIME;
+		VOP_LEASE(ndp->ni_vp, p, p->p_ucred, LEASE_WRITE);
+		vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, p);
+		(void) VOP_SETATTR(ndp->ni_vp, &vattr, p->p_ucred, p);
+		VOP_UNLOCK(ndp->ni_vp, 0, p);
+	}
+#endif
+
 exec_fail_dealloc:

%%%

The patch in the PR is not good since it assumes that all filesystems are ufs.

Bruce

	Hello.  Having not read these patches thoroughly, it's unclear
to me if they cause the atime field to be updated if a segment of an
executable is paged-in during program execution, i.e. when new data needs
to be paged in for a daemon process, but historical behavior on FreeBSD, as
well as other BSDish systems suggests that it should.  Also, I note that
the bug is still present in FreeBSD-4.7 stable as of December 2002.  It
would be very nice if someone could make this work in FreeBSD 4.x again,
or, at the very least, correct the problem in FreeBSD-5.1.  
-thanks
-Brian

I just spent roughly two nights to hit the same problem; I'm developing
a KDE frontend to the ports system
<http://www.student.uni-oldenburg.de/frerich.raabe/barry>, and a feature of
that frontend is that it can (or rather, it tries to) find unused packages.
It does so by checking all plists for the installed packages, looking for
whether there's at least one file in a plist which hasn't been accessed in
the last n days. If that's true, the respective package might be subject
for removal, and is suggested as such.

Unfortunately, since this bug exists, the atime of executables (which I use
for determining when a file has last been accessed, of course) does not get
bumped when the executable gets run, hence the port frontend keeps
suggesting things like "gmake", even though I run that on a daily basis.

I'd really appreciate it if you could fix this bug, at least for FreeBSD 5.1.
Thanks!

Comment 5 Mark Linimon 2008-01-26 14:36:29 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-standards

It sounds as though from the audit-trail that this might be in 
the 'standards' realm. 

Pointed out by:		BSDTron on EFNet

Comment 6 Gavin Atkinson 2008-06-25 16:59:36 UTC

State Changed
From-To: feedback->open

The requested feedback was provided in August 2002

Comment 7 Mark Linimon 2009-06-09 23:36:28 UTC

State Changed
From-To: open->closed

Appears to have been fixed in the meantime; reports are that it works in 
6, 7, and 8. 

Thanks for your patience.