7

I have an hourly hour-long crontab job running with some mtr (traceroute) output every 10 minutes (that is going to go for over an hour prior to it being emailed back to me), and I want to see the current progress thus far.

On Linux, I have used lsof -n | fgrep cron (lsof is similar to BSD's fstat), and it seems like I might have found the file, but it is annotated as having been deleted (a standard practice for temporary files is to be deleted right after opening):

COMMAND     PID       USER   FD      TYPE     DEVICE  SIZE/OFF       NODE NAME
...
cron      21742       root    5u      REG      202,0      7255      66310 /tmp/tmpfSuELzy (deleted)

And cannot be accesses by its prior name anymore:

# stat /tmp/tmpfSuELzy
stat: cannot stat `/tmp/tmpfSuELzy': No such file or directory

How do I access such a deleted file that is still open?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
cnst
  • 3,223
  • 2
  • 23
  • 44

1 Answers1

13

The file can be access through the /proc filesystem: you already know the PID and the FD from the lsof output.

cat /proc/21742/fd/5
cnst
  • 3,223
  • 2
  • 23
  • 44
  • These are symbolic links to the file... does it still work when the file is deleted? – Bonsi Scott Jan 19 '13 at 11:09
  • 4
    @BonsiScott: Every files in `/proc` is fake. For `/proc/*/fd/` files, When calling `stat` on them, they tell you it's a symbolic link, when you call `readlink` on them, they return whatever they want (in this case, an absolute path to the file that was opened), and when you call `open` and `read` on them, you get access to a somewhat real file with content. The same holds true for many files in `/proc`. For example, most dynamically generated files have a file size of zero, yet they have contents. – BatchyX Jan 19 '13 at 14:55
  • 1
    Many tools also allow you to deliberately dereference symlinks - for example, I used `ls -l --dereference-command-line /proc/1234/fd/5` to check the size of an open but deleted file. – Zanchey May 06 '15 at 01:56