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/sunmanagersReceived 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