SUMMARY: iNode Modification time changing

From: Richard Hirst <richard.hirst_at_pipex.net>
Date: Tue Oct 16 2007 - 06:15:52 EDT
Thanks to everyone for the input, especially Ric Anderson who put the
information most succinctly:

 

"This is a nasty side effect of Backup Exec's Solaris client and possibly
other similar tools.  What BE does is read the file which changes its
st_atime, then BE does a utime() to put back the original st_atime, which in
turn changes st_ctime.

Since BE runs as a daemon, you don't see any footprints in logs indicating
anything "ran" when all the ctimes changed.

 

A full backup using backup exec will alter the ctime on every file depending
on directory lists in

   /etc/bkupexec/agent.cfg

Newer versions of BE have an option to not do the utime(), but that means
the access time of every file will change across a full backup."

 

Original Question:

We are running Solaris 9 on a number of servers. We run tripwire to monitor
changes and check the integrity of the systems. On some of the servers, at a
fairly regular interval, the inode modification time of (almost?) all files
is updated, making the output from tripwire pretty useless. An example of
the output is below:

 

/usr/sbin/psrset

      st_ctime: Sun Oct 14 07:48:55 2007      Thu Sep 27 08:04:19 2007

---> File: '/usr/sbin/psrset'

---> Update entry?  [YN(y)nh?]

 

bash-2.05# ls -lc /usr/sbin/psrset

-r-xr-xr-x   1 root     sys        12576 Oct 14 07:48 /usr/sbin/psrset

 

I've checked the md5 of some of these files against the Sun fingerprint
database, and they check out.

 

There was nobody logged in at the time of the changes, and nothing running
in cron (other than sar).

 

Any suggestions as to why this is happening would be much appreciated!
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Tue Oct 16 06:16:08 2007

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:07 EST