21

Just for fun:
Is there a way to monitor/capture/dump whatever is being written to /dev/null?

On Debian, or FreeBSD, if it matters, any other OS specific solutions are also welcome.

Gilles 'SO- stop being evil'
  • 829,060
Ali
  • 6,943
  • 3
    Possible, but as the answers and comments describe it's /very/ much not a good idea. – Shadur-don't-feed-the-AI Feb 17 '12 at 17:38
  • 2
    @Shadur: There might be bad solutions but that doesn't make the idea uninteresting or a bad idea. – jlliagre Feb 18 '12 at 20:36
  • 1
    Indeed, I just found this question because I was considering what an analysis of the content from many captured /dev/nulls might turn up. I wouldn't want to do the research myself, but I'd love to read the results. (There would very likely be some ethical issues in "looking through people's trash" essentially, but the concept is interesting nonetheless.) – beporter Nov 14 '14 at 15:13

3 Answers3

12

Making /dev/null a named pipe is probably the easiest way. Be warned that some programs (sshd, for example) will act abnormally or fail to execute when they find out that it isn't a special file (or they may read from /dev/null, expecting it to return EOF).

# Remove special file, create FIFO and read from it
rm /dev/null && mkfifo -m622 /dev/null && tail -f /dev/null
# Remove FIFO, recreate special file
rm /dev/null && mknod -m666 /dev/null c 1 3

This should work under all Linux distributions, and all major BSDs.

Chris Down
  • 125,559
  • 25
  • 270
  • 266
5

I once found out the hard way that /dev/null doesn't have to be a special dev file. A long time ago the /dev/null on an Ultrix system at work got deleted, so the next time a program redirected to /dev/null, it ended up being a normal file full of the output from that program. (I think it was 'no such file or directory', which meant when we were trying to figure out what was going on, we'd do cat /dev/null and be told no such file or directory which confused the hell out of us.)

So my suggestion would to be replace it with a named pipe, and then attach a program to the pipe that would read it and monitor it.

Paul Tomblin
  • 1,678
  • 4
    A lot of programs also rely in /dev/null always returning 0 bytes on a read (cat /dev/null > foo). Having /dev/null be a regular file with contents, would break this expectation. – Arcege Feb 17 '12 at 16:44
  • 1
    Yes, that's how we discovered it. Programs were expecting no input and getting gobs of it, plus /dev/ was getting filled up. – Paul Tomblin Feb 17 '12 at 16:53
1

I think of an idea where /dev/null can be a symlink to a file descriptor but with add code mechanism to determine the operation is read or write and then if it is read, it should actually read from /dev/actualnull created seperately with mknod and if it is write then make a note of the invoking program and attempt to log/count for analyzing the programs that use /dev/null for writing. This is going to cost a lot in terms of performance, I suppose though. I guess it is not practical since most shell programs or code use redirection anyway. May be inotify could be used to monitor the usage of /dev/null ? or rewrite the kernel code that handles 1:3 devices, again compile and reinstall, experimentable.

Nikhil Mulley
  • 8,315
  • 2
    There are still some problems, I tried doing something like this (not in-kernel, but transparently-ish by allowing to read from another file and controlling /dev/null from a daemon), and sshd still complained and wouldn't start. – Chris Down Feb 18 '12 at 18:41
  • hmm..interesting on /dev/null controlling from a daemon. I think most programs just would want to use /dev/null as just another file leaving the importance and semantics of /dev/null to the system. – Nikhil Mulley Feb 19 '12 at 02:24
  • Well, sshd (at least, as packaged for Debian Squeeze) complains with sshd: cannot create /dev/null if it's anything but the most common implementation. – Chris Down Feb 19 '12 at 06:46