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.

Improve this question
3
  • 3
    Possible, but as the answers and comments describe it's /very/ much not a good idea. Commented Feb 17, 2012 at 17:38
  • 2
    @Shadur: There might be bad solutions but that doesn't make the idea uninteresting or a bad idea. Commented Feb 18, 2012 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.) Commented Nov 14, 2014 at 15:13

3 Answers 3

Reset to default
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.

Improve this answer
6
  • 1
    One thing to note is that if the tail fails, then a lot of programs may fail because the pipe's buffer is full. Commented Feb 17, 2012 at 16:44
  • 4
    Programs that read from /dev/null aren't going to like this. Commented Feb 17, 2012 at 16:53
  • @Gilles - Indeed, hence my note. Commented Feb 17, 2012 at 17:14
  • 3
    @Ali Yes. No magic is a guiding principle in the UNIX philosophy. Commented Feb 17, 2012 at 19:49
  • 4
    Ahem /dev/null is magic, mknod /dev/null c 1 3 is the magic formula to invoke it. (And you need super-powers for that…) Commented Feb 17, 2012 at 21:55
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.

Improve this answer
2
  • 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. Commented Feb 17, 2012 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. Commented Feb 17, 2012 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.

Improve this answer
3
  • 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. Commented Feb 18, 2012 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. Commented Feb 19, 2012 at 2: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. Commented Feb 19, 2012 at 6:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.