Bug 5600 - ash shell backtick never returns if sub-process closes std file descriptors
Summary: ash shell backtick never returns if sub-process closes std file descriptors
Status: NEW
Alias: None
Product: Busybox
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.19.x
Hardware: Other Linux
: P5 minor
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-11 20:09 UTC by Jim Edwards
Modified: 2012-10-15 13:55 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Edwards 2012-10-11 20:09:15 UTC
It seems there is some kind of a problem in the ash shells implementation of back-tick (or variable execution).  If you try and start a process which closes the stdout/stderr file-descriptors in the back-tick, then the back-tick operation never returns, even though the sub-process has exited.  This was originally report when udev was started as a daemon, for example:

echo "Running UDEV"
OUPUT=`udevd -d`
echo "Returned ${OUTPUT}"

would output:

Running UDEV
<hang forever>

I noticed back in 2003 there was a patch for a similar problem for the msh shell in busybox.
Comment 1 Denys Vlasenko 2012-10-15 13:55:46 UTC
Trying to reproduce:

$ strace -oLOG -s99 -f -tt ./busybox ash -c 'echo T1 `exec <&- >&- 2>&-` T2'
T1 T2
$

and strace log looks normal.
Adding a pause:

$ ./busybox ash -c 'echo T1 `exec <&- >&- 2>&-; exec sleep 1` T2'
<one second pause>
T1 T2
$

Still looks ok.

Are you sure that in your case: OUPUT=`udevd -d`, udevd does not forget to close stdout when it daemonizes? If it does, then shell will be blocked reading from it. Try OUPUT=`udevd -d </dev/null >/dev/null 2>&1`