Red Hat Bugzilla – Bug 61610
rc.sysinit fails when /dev/null has been corrupted
Last modified: 2014-03-16 22:26:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
The /etc/rc.d/rc.sysinit script fails rather badly if the /dev/null
file has become corrupted. rc.sysinit fails right at the top when
it tried to mount /proc.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: The system fails to boot. You get very weird error messages
that don't lead to easy problem resolution... at least not for me... The error
mounting proc: file system dup2:bad file descripter
Configuring kernel parameters: dup2:bad file descripter
Setting Clock: dup2:bad file descripter
The script ends up dropping you into the maintenance shell after it
fails to fsck the file system. I initially thought I had a corrupt
file system because of the error messages. I found some references
through Google about people rebuilding their system because of this
Expected Results: The system should *always* boot.
Patch to rc.sysinit
<<<< start patch >>>>
> # Test for a valid /dev/null, remake the file if it's been corrupted.
> if [ ! -c /dev/null ]; then
> echo "The /dev/null file has been corrupted... Fixing..."
> mount -n -o remount rw /
> rm -f /dev/null
> mknod /dev/null c 1 3
> chmod 0666 /dev/null
> umount /
<<<< end patch >>>>
The patched rc.sysinit will test the /dev/null file and replace
it with a new charactor special device when required. This patch
assumes that /dev resides under the root filesystem. It will not
cause any (more) problems if /dev/null gets corrupted and the
/dev dir resides in another partition.
You *might* want to put this patch into the shutdown script
instead of rc.sysinit. It might be cleaner...
I am having exactly the same failure on an Compaq iPAQ Celeron 800 and an
Compaq Prolian ML370 Server.
Thank you for the tipp :)
I am having similar issues as well, does anyone have a solution to why
/dev/null is corrupting or just this workaround?
It's just a workaround for an annoying little bug with a really
screwy failure mode.
In my case, shell scripts running as root caused the corruption. I
had written a script to check the process table and start (or
restart) a large number of *really* junky vendor programs. The
STDOUT and STDERROR for the programs were redirected to /dev/null.
I suspect the vendors programs behaved badly and somehow
overwrote /dev/null through the shell redirect. I was
seeing /dev/null changed to a normal file instead of a special file.
I only had the problem occur a few times. I also had a script
running from cron, which checked /dev/null every hour, fixed it as
necessary, and emailed me an alert. I was never able to figure out
the actual mechanism causing the problem. The issue went away when I
forced the vendor to rewrite their programs to use a common user
account instead of root.
Closing bugs on older, no longer supported, releases. Apologies for any lack of
This should be fixed in current releases with the move to udev, with /dev being
recreated on each boot.