When I do lsof +c 0 | grep /dev/zero, I see the following two lines:

sshd    19064    root  DEL    REG    0,4    497862    /dev/zero
sshd    19064    root  DEL    REG    0,4    498725    /dev/zero

The DEL keyword is what intrigues me - from the manpages, it means:

DEL for a Linux map file that has been deleted

However, last time I checked my /dev/zero was still there, even if I reboot... So why would sshd attempt to delete this character device and why would it even succeed given that:

  • It is a character device, not a file
  • it is owned by root

OS info: Linux localhost 3.4.103 #1 SMP PREEMPT Thu Dec 18 13:07:12 CST 2014 armv7l GNU/Linux (Arch Linux)

  • I would interpret the DEL flag as "The file opened and the file on disk are not the same", i.e. manipulating the file on disk will not influence the process. At least that makes sense for /dev/zero. – michas Feb 8 '15 at 10:38

DEL doesn't indicate that that process deleted /dev/zero, but that that process is using /dev/zero and the instance of /dev/zero that was being used has since been deleted. For example, if I have a command (say some-command) that uses /some/file and I do:

$ some-command &
$ rm /some/file
$ touch /some/file

Then lsof for /some/file would look like:

some-command    ...    ...  DEL    ...    ...    ...    /some/file

The contents of the deleted file continue to remain on disk until the process lets go or is killed, but won't be directly accessible.

The version of /some/file that I created using touch is not the one that some-command is using.

  • Okay, that helps a lot... However, should it then not show this for each process that ever read something from /dev/zero? It's a stream of characters and each process could potentialy read different amount of them, thus having a "different version" of it. Alternatively, how can anyone know when such a device has changed, or even change it (since writing to it behaves identically to writing to /dev/null)? Or, does this simply mean that perhaps sshd did not close the file descriptor yet (or some such thing), thus showing on the list...? – Robert Rossmann Feb 8 '15 at 11:13
  • @RobertRossmann The last is correct. sshd opened /dev/zero, /dev/zero got deleted, sshd has not yet closed the fd. The kernel knows, since it keeps track of fds and what the fd points to. Notice that in my example, some-command is sent to the background, so it would (presumably) still be running when I deleted and ran lsof. – muru Feb 8 '15 at 11:15
  • Great, I am starting to understand.:) It still implies, though, that /dev/zero got somehow modified while sshd was using it - how could such thing happen if, when written to, does nothing and when read from, returns the same data (albeit a variable length)? How does the kernel determine that the file has changed? PS. Writing to it does not change mtime... – Robert Rossmann Feb 8 '15 at 11:22
  • Yes, writing to it doesn't change any of its times, but any process running as root can delete and recreate it (sudo mknod /dev/zero c 1 5). The kernel can know when a file is accessed, written to, modified, deleted, etc. - that's why inotify is possible. – muru Feb 8 '15 at 11:30
  • As to what deleted it, who knows? That will be hard to discover. – muru Feb 8 '15 at 11:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.