7

I'd like to better understand which programs are modifying a specific file1 during a reboot. Can I set something up to log this kind of information?

Polling for which processes currently have the file open won't work, as the file may only be open for a few milliseconds.

Can kernel tracing be used to collect this information?


1 /var/lib/alsa/asound.state if you're curious, but I'm interested in a general solution.

ændrük
  • 76,794

1 Answers1

2

This can be achieved with the fuser tool. It lists the process ID of all processes accessing a specific file. Try,

fuser -u .

...to see which files are "open" in your home directory, the process ID's involved and the username owning those processes.

In your case, I'm not sure this will be useful since you're trying to monitor a reboot. I suspect that rc.local will execute too late in the reboot to capture anything useful with, say,

watch -n 0.5 "fuser -u /var/lib/alsa/asound.state"

Hmm - I've just tried dumping this to a file and the output isn't very pretty. But if this can be resolved, then perhaps something can be achieved with cron?

Scaine
  • 11,139
  • 2
    lsof is another tool that might be useful, if it is wrapped in something. – belacqua Feb 02 '11 at 21:01
  • Not come across that, but you're right - lsof has better output actually! It lists the name of the process, the user, the PID, the name of the file and more. – Scaine Feb 02 '11 at 21:32
  • I don't think -f does anything. (Source) – ændrük Feb 02 '11 at 23:28
  • 1
    I would keep the- f to make this command more interesting to read aloud. – Jim Schubert Feb 03 '11 at 00:38
  • As far as I can tell from the man pages, both fuser and lsof can only report what is occurring at a given instant. For all I know, however, the file may only remain open for a fraction of a second. How frequently would I need to poll with these tools to be sure not to miss the file being opened? – ændrük Feb 03 '11 at 03:55
  • 1
    I've removed the -f (the man page states that it's silently ignored anyway). ændrük, I have no idea how to capture the information that fast. I find the output from tailing the watch command pretty difficult to read anyway, so running it with say -n .1 will be even uglier. I think another solution may be required. Sorry. – Scaine Feb 03 '11 at 16:43