Bug 61610 - rc.sysinit fails when /dev/null has been corrupted
rc.sysinit fails when /dev/null has been corrupted
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2002-03-21 22:10 EST by Steve Daggett
Modified: 2014-03-16 22:26 EDT (History)
2 users (show)

See Also:
Fixed In Version: FC3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-29 15:45:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Daggett 2002-03-21 22:10:49 EST
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):

How reproducible:

Steps to Reproduce:
1.rm /dev/null
2.touch /dev/null

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
messages read:

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.

Additional info:

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 /
> fi
<<<< 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...
Comment 1 Christian Jacobsen 2002-05-14 08:07:27 EDT
I am having exactly the same failure on an Compaq iPAQ Celeron 800 and an 
Compaq Prolian ML370 Server.
Thank you for the tipp :)
Comment 2 John Strange 2004-02-24 09:39:47 EST

I am having similar issues as well, does anyone have a solution to why
/dev/null is corrupting or just this workaround?
Comment 3 Steve Daggett 2004-02-24 13:06:38 EST
  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.  

Steve Daggett
Comment 4 Bill Nottingham 2005-09-29 15:45:49 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.