Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 2 down vote favorite

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
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. – GregS 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
show 7 more comments

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

2 Answers

up vote 4 down vote

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
up vote 3 down vote

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

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.