[BusyBox 0001597]: If stdout is not open, redirection to a file causes that file to always be used as stdout
bugs at busybox.net
bugs at busybox.net
Wed Feb 13 15:39:10 UTC 2008
The following issue has been CLOSED
======================================================================
http://busybox.net/bugs/view.php?id=1597
======================================================================
Reported By: vomlehn
Assigned To: BusyBox
======================================================================
Project: BusyBox
Issue ID: 1597
Category: Other
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 11-19-2007 11:40 PST
Last Modified: 02-13-2008 07:39 PST
======================================================================
Summary: If stdout is not open, redirection to a file causes
that file to always be used as stdout
Description:
I am booting an INITRAMFS filesystem in which /init is a script that starts
with "#!/bin/sh" and, so, invokes busybox. My console is a USB serial
device and things work normally if I have a serial device attached. If I
boot my system with no USB serial device attached, the open of
/dev/console fails and the busybox has no open file descriptors when it
starts.
In my /init script, I use:
echo /sbin/hotplug >/proc/sys/kernel/hotplug
The correct data is put into that pseudo-file. The problem is that
subsequent output is *also* put into that pseudo-file. This is a big
problem since my hotplug script is no longer getting run.
My guess is that, when cleaning up after a command, busybox closes all
file descriptors except for 0, 1, and 2 (standard in, out, and error).
This would be incorrect behavior. I think it should close *every* file
descriptor opened by the command. This would restore it to having no file
descriptors open, which would prevent data from going to the wrong file.
There appear to be two ways to implement this:
1. Keep track of every open and close, and close everything opened during
invocation of a command.
2. Determine whether file descriptors 0, 1, and 2 are open at
initialization, at command termination, close each one that wasn't open.
======================================================================
----------------------------------------------------------------------
vda - 11-19-07 17:23
----------------------------------------------------------------------
Which version of busybox do you use? Sometime ago, busybox's init was
changed
to NOT try to open /dev/console, but just use whatever fd's were passed to
it by kernel.
Which shell is configured to be "sh" (ash,msh,hush,lash?)
----------------------------------------------------------------------
vda - 11-19-07 17:24
----------------------------------------------------------------------
Oh, I see. You don't use busybox's init. so that fix is not applicable. But
I still need to know version and shell.
----------------------------------------------------------------------
vda - 11-19-07 19:11
----------------------------------------------------------------------
Also, can you show your /init shell script? Can be useful too
----------------------------------------------------------------------
vomlehn - 11-20-07 10:25
----------------------------------------------------------------------
I now have a work-around for this issue. Instead of trying to do much work
in the /init script, I have a much shorter /init script. In the new /init,
I mount the /proc filesystem and see if I have a /proc/self/fd/1 file. If
so, standard output is open and I just exec a script named /init1, which
does what /init used to do. If standard output is not open, I exec /init1
but redirect standard output and standard error to /dev/null:
exec /init1 1>/dev/null 2>&1
This way I actually have file descriptors 1 and 2 open. This makes
everything work correctly.
Additional info:
o I am using ash.
o In implementing the work-around, I changed my /init script, but it
basically used to look like:
------------------- Cut Here -----------------------
#!/bin/sh
echo Mounting /proc filesystem
mount -t proc /proc /proc
echo Mounting /dev filesystem
mount -t tmpfs none /dev
echo Mounting /sys and starting mdev
mount -t sysfs sysfs /sys
echo /sbin/mdev >/proc/sys/kernel/hotplug
mdev -s
echo "Installing platform driver"
insmod platform.ko
echo Installing ide driver
insmod ided.ko
------------------- Cut Here -----------------------
The problem was that the output from echo was winding up in
/proc/sys/kernel/hotplug, so when I insmod-ed the IDE driver, the kernel
tried to run the hotplug program "Installing ide driver". Silly kernel.
So, my /dev/hda* devices never got created.
----------------------------------------------------------------------
vomlehn - 11-20-07 10:26
----------------------------------------------------------------------
...and I am using version 1.8.1 of busybox. No patches applied.
----------------------------------------------------------------------
vda - 11-21-07 22:25
----------------------------------------------------------------------
Please try attached 5.patch
----------------------------------------------------------------------
vda - 02-13-08 07:39
----------------------------------------------------------------------
Fixed in svn sometime ago.
Issue History
Date Modified Username Field Change
======================================================================
11-19-07 11:40 vomlehn New Issue
11-19-07 11:40 vomlehn Status new => assigned
11-19-07 11:40 vomlehn Assigned To => BusyBox
11-19-07 17:23 vda Note Added: 0002940
11-19-07 17:23 vda Status assigned => feedback
11-19-07 17:24 vda Note Added: 0002941
11-19-07 19:11 vda Note Added: 0002942
11-20-07 10:25 vomlehn Note Added: 0002943
11-20-07 10:26 vomlehn Note Added: 0002944
11-21-07 22:25 vda File Added: 5.patch
11-21-07 22:25 vda Note Added: 0002947
11-22-07 00:17 vda File Deleted: 5.patch
11-22-07 00:17 vda File Added: 5.patch
02-13-08 07:39 vda Status feedback => closed
02-13-08 07:39 vda Note Added: 0004384
======================================================================
More information about the busybox-cvs
mailing list