Thread: What's touching this file?

Sorry for the long delay in updating (over 24 hours!? Outrageous!). I'm giving auditd a chance; inotify fired off once or twice, but the output from ps aux was ... inconclusive. Thanks!

Hmm... I thought inotifywatch had a way to record PIDs of the offending process, but I guess not. Your plan looks good, though if the file is just being touched, it may be too fast to see. The other thing that comes to mind is to create a tarpit by symlinking /home/me/1 to something that will block. You could use a broken network mount, I can't think of anything less hacktastic

quote: Originally posted by euzeka: Quite likely. I get '1' files every now and then from mistyped stdout redirects or using syntax for the wrong type of shell. Might be worth looking into (eg. it could be a cron job after all). This. The likely syntax should look like this: job > /dev/null 2>&1 But you would have an output file "1", that could be size zero depending on output, if you used this incorrect...

I'm guessing lsof isn't showing anything holding onto the file?

Show it a doll, and ask it to use the doll to show you.

It's in your home directory, so it's probably one of your processes, not root's. It's called 1 so it's probably a typo in a bash script somewhere - something like "- 1" instead of "-1" or something.

quote: Originally posted by bombcar: It's called 1 so it's probably a typo in a bash script somewhere - something like "- 1" instead of "-1" or something. Quite likely. I get '1' files every now and then from mistyped stdout redirects or using syntax for the wrong type of shell. Might be worth looking into (eg. it could be a cron job after all).

It should work to add that file to the list of files for auditd, and then look at the audit log. It's been forever since I messed with auditd, so I don't remember the syntax.