Search code examples
linuxbashsymlinkprocfs

Broken symlinks and a mysterious (deleted)


I've been doing stuff with the proc filesystem on linux, and I've come across some behavior I'd like to have clarified.

Each process in /proc has a symlink to it's executable file, /proc/{pid}/exe. If a process continues to run after it's executable has been deleted, reading this symlink will return the path to the executable, with (deleted) appended to the end.

Running this command you may even see a few on your system:

grep '(deleted)' <(for dir in $(ls /proc | grep -E '^[0-9]+'); do echo "$dir $(readlink /proc/$dir/exe)"; done)

I tried recreating this behavior with some simple bash commands:

>>> echo "temporary file" >> tmpfile.test
>>> ln -s tmpfile.test tmpfile.link
>>> rm tmpfile.test
>>> readlink tmpfile.link
tmpfile.test

There is no (deleted) appended to the name! Trying a cat tmpfile.link confirms that the link is broken (cat: tmpfile.link: No such file or directory).

However, the other day this same test did result in a (deleted) being appended to the output of readlink. What gives?

Here is what I would like to know:

  • Is there a sequences of events that guarantees (deleted) will be appended to the name?
  • Why does /proc/{pid}/exe show (deleted) for removed executables?
  • How can I get the name of an executable through /proc/{pid}/exe without any appended (deleted) and guarantee that the original executable wasn't just named some_executable (deleted)?

Solution

  • It is not readlink, but Linux changes the symlink to point to <filename> (deleted), i.e., (deleted) gets appended to the target of the link.