Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 12 down vote favorite
3

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.

share|improve this question
3  
Possible, but as the answers and comments describe it's /very/ much not a good idea. – Shadur Feb 17 '12 at 17:38
1  
@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

3 Answers

up vote 11 down vote accepted

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.

share|improve this answer
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. – Arcege Feb 17 '12 at 16:44
4  
Programs that read from /dev/null aren't going to like this. – Gilles Feb 17 '12 at 16:53
@Gilles - Indeed, hence my note. – Chris Down Feb 17 '12 at 17:14
3  
@Ali Yes. No magic is a guiding principle in the UNIX philosophy. – phihag Feb 17 '12 at 19:49
2  
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…) – Stéphane Gimenez Feb 17 '12 at 21:55
show 1 more comment
up vote 1 down vote

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.

share|improve this answer
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 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. – Chris Down Feb 19 '12 at 6:46
up vote 4 down vote

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.

share|improve this answer
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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