How to detect a "touch" (Ignore earlier post with same title)

[Jason Cannon]

There is a file on one of my hpux 11.00 servers that is being updated (actually I think touched) every minute on the minute. It's almost like it's a cron or at job, though no such jobs exist. I would like to find the process that is doing this.


I've tried using lsof and fuser. I fire them off in a continuous loop but they never expose the process touching the file. I'm pretty sure that lsof and fuser don't detect "touch" as touch is just changing a directory entry or something to that effect, right?

Any ideas?

Thanks!

Jason

[Shahul]

Hi,

Try changing permission of this file and directory. Then you may get that particular job is failing. This is one of the way you can trace this hidden job.

Good luck
Shahul

[Patrick Wallek]

You might be able to accomplish this with the auditing subsystem. You could turn on auditing and possibly have it monitor just this one file. The audit logs I think should then tell you who or what changed it.

[A. Clay Stephenson]

What actually changes is the files inode. This is where the file metadata is stored and thewre are 3 times of interest: 1) mtime - time of last file modification 2) ctime - time of last change (e.g. chmod) 3) atime - time of last access. You can use ls -l, ls -lc, and lc -lu respectively to display these times for a given file. Looking at the other times might give you a better clue.

I would tend to loop do ps -e's to a file with a datestamp between each ps and compare those to the file times. You should get lucky at some point.

There is no direct method to know which process last accessed a file. That is simply not carried in the inode.

[Jason Cannon]

Patrick,

I just tried to turn on auditing via SAM and I get an error msg:

"This system is configured as either an NIS server or an NIS client. Converting a system configured for NIS to a trusted system is not allowed. These two features are not supported together."

So, that doesn't look like an option at the moment. Great suggestion though... and one I would have never thought to try.

Thanks!

Jason

[Todd McDaniel_1]

I might do something like this on the command line...

while true
do
ps -aef |grep touch > touch.file.out
cat touch.file.out
sleep 5
done

You can change the sleep time... if it is too short. Then capture the pid

[Michael Schulte zur Sur]

Hi,

replace the touch command with a script. Rename the touch into touch touch.old and create a script touch with:
date >> /usr/bin/touch.log
ps -ef >> /usr/bin/touch.log
touch.old $*
Then you will see any calling of touch.

greetings,

Michael

[Sridhar Bhaskarla]

Hi Jason,

All 'touch' does is basically to use the system call 'utime' to update the access and modification times. If the process simply touches the file, it will not be captured by fuser or lsof.

I would also follow the same 'ps' and datestamp procedure. If I can find out the processes within that particular instant of time with 'ps', then I would run tusc on these processes (cumbersome ofcourse) and see what process was using utime on this file.

But if the process is actually "opening" the file, then you can get information from fuser or lsof if you use them against the filesystem holding the file. Write a script that does a diff of the previous and current outputs and write it it into the file.

-Sri

[G. Vrijhoeven]

Hi,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=365213

Gideon

[Jason Cannon]

I used Michael's touch script and thus have determined that whatever is updating the file is not using /usr/bin/touch. I did a find for touch just in case someone had a copy laying around, but didn't find one.

This is strange...

Jason

[Darren Prior]

Hi Jason,

Is this a system file, or one in an application or data dir?

Did you have any luck changing the permissions of the file/dir to see if some other app/script logged an error?

regards,

Darren.

[Jakes Louw]

Have a look in /var/adm/cron/log.

Alternatively, run top or glance to see if you can see the process.
Also, have a look at jobs that have been running under the same user as the file owner for some time. Could be he has a program that's running in a loop that he has forgotten about?