Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On Debian stable, python 2.6.4

I have a script that overwrites /dev/null.

Any idea as to what could be happening?

The only thing I have is a typical cron job that redirects output to /dev/null, but that should not cause that, right?

share|improve this question

migrated from stackoverflow.com Jan 2 '11 at 19:49

This question came from our site for professional and enthusiast programmers.

2  
There's no way that would be happening unless your script was running as root, and even then it's non-trivial. – Adam Rosenfield Jan 2 '11 at 18:26
1  
Overwrites? /dev/null is an infinite sink of data. – James K Polk Jan 2 '11 at 18:27
    
I think this would be better tagged linux instead of python and debian. – Jo Liss Jan 2 '11 at 18:28
    
Belongs to serverfault – ismail Jan 2 '11 at 18:34
3  
Actually superuser, I think, since this is advanced usage of linux, nothing particularly server-ish. – Ben Voigt Jan 2 '11 at 18:42

My guess is that some script running with root rights is moving its output into place. So it does something like

... write data ... > /tmp/foo.$$.tmp
mv /tmp/foo.$$.tmp "$DEST"  # where "$DEST" is /dev/null -- ouch!
share|improve this answer
    
The only thing I have running are python scripts (which I wrote) so I know there's nothing like that in them, and a crontab job that looks like this: * * * * * /scripts/allmonitor.py 2>&1 > /dev/null – Christopher Mahan Jan 3 '11 at 16:06
    
Are you sure? Maybe something in one of the /etc/cron.*/ directories? Or some misconfigured startup script? The redirect you posted shouldn't break /dev/null (though what you meant is correctly written &> /dev/null or > /dev/null 2>&1 in that order). The answer above is all that my crystal ball produces -- without more information it's impossible to remote-debug your problem. – Jo Liss Jan 4 '11 at 20:14
    
I'll redo the > /dev/null 2>&1 part and let you know. – Christopher Mahan Jan 24 '11 at 23:47

Once /dev/null has been clobbered once, any attempt to write to it will replace it with a file. You have to recreate it using mknod.

Ok, I take that back - Debian stable uses udev, so you can recreate the stuff in /dev just by rebooting. Back when men were men and Sun OS required to you recompile if you wanted more semaphores, a group of us spend some time trying to figure out why one part of our program was giving strange answers, until we realized that stdin was directed from /dev/null, and /dev/null had been replaced by a normal file, so every time it ran it got as input whatever had been output the last time somebody ran a program with the output redirected from /dev/null.

share|improve this answer
    
It will also be recreated when you reboot. – user38584 Jan 2 '11 at 19:00
    
Does Debian stable use udev? I thought it didn't. – Paul Tomblin Jan 2 '11 at 19:03
    
Rebooting didn't restore /dev/null – Christopher Mahan Jan 24 '11 at 23:48
    
So if /dev/null is a normal file instead of block special, what's in it? Maybe the contents could tell you who is filling it? – Paul Tomblin Jan 25 '11 at 12:15
    
@Christopher, if rebooting doesn't restore /dev/null, you probably do not have the /dev file system mounted properly. mount should give you a line like none on /dev type devtmpfs (rw,mode=0755). – Jo Liss Oct 3 '11 at 19:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .