Bug 359371

Summary: pipes not handled correctly in eval ticks
Product: [Fedora] Fedora Reporter: Sergio Freire <etfreire>
Component: busyboxAssignee: Ivana Varekova <varekova>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 7CC: nhorman
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-01 12:30:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sergio Freire 2007-10-30 23:16:29 UTC
Description of problem:
It seems that busybox has a problem handling pipes inside eval ticks. If you
pipe the output of one command to another inside eval ticks and return that into
some variable, the variable is not set.
It might be a regression bug. 

Version-Release number of selected component (if applicable):
1.2.2-8.fc7
(also applies to busybox-1.7.2-2.fc9.i386.rpm from the upcoming Fedora9)

How reproducible:
always

Steps to Reproduce:
1. install kexec-tools 
2. force a crash using "echo c > /proc/sysrq-timer"  - you see that the init
process of the kernel used by kexec fails..
2. another way to reproduce is to edit mkdumprd and add a line after the emit
"echo Creating Block Devices" line, something like: 
      emit "/bin/msh"
3. remove the initrd used for the kexec+kdump
2. rebuiild the inirtd for the kexec+kdumo, using the modified mkdumprd
3. force a system crash using "echo c > /proc/sysrq-timer"
4. execute:

# a=`ls /`
# echo $a
... (you see the directories in the root directory)
# a=`ls / | grep i`
# echo $a
(you don't see any directory)

  
Actual results:
In latter example above, the "a" variable is empty.

Expected results:
The pipe should work inside eval ticks. In this case you should see the
directories that have "i" somewhere in the name.

Additional info:
Also affects the RPM of the upcoming Fedora9. See above. You might reproduce
this easier without kexec-tools but this was the scenario that I was testing at
the moment I found this.

Comment 1 Sergio Freire 2007-10-30 23:20:19 UTC
This also affects the "kexec-tools" package indirectly, since you won't be able
to boot the kernel using kexec because it fails processing the initrd created by
mkdumprd.

Comment 2 Sergio Freire 2007-10-30 23:59:08 UTC
This bug is not present on busybox-1.2.0-3.i386.rpm from RHEL5.

Comment 3 Ivana Varekova 2007-10-31 16:15:04 UTC
I was not able to reproduce this problem. Please could you describe the steps to
reproduce more precisely, I'm not sure with the order of commands. It would be
fine if you choose some shorter way how to reproduce the problem (The best would
be a sequence of busybox commands). Thanks.

Comment 4 Sergio Freire 2007-10-31 20:37:25 UTC
Ok, do as follows.

# busybox msh
[root@localhost ~]# busybox msh
root:~> a=`/sbin/busybox ls / `
root:~> echo $a
bin boot dev etc home lib lost+found media misc mkinitrd mnt net opt proc root
sbin selinux srv sys tmp usr var
root:~> a=`/sbin/busybox ls / | /sbin/busybox grep i`
root:~> echo $a

root:~> a=`/sbin/busybox ls / `




in a good busybox version:
==========================
# busybox msh
root:~> a=`/sbin/busybox ls / `
root:~> echo $a
bin boot dev etc home lib lost+found media misc mkinitrd mnt net opt proc root
sbin selinux srv sys tmp usr var
root:~> a=`/sbin/busybox ls / | /sbin/busybox grep i`
root:~> echo $a
bin lib media misc mkinitrd sbin selinux
root:~>




Comment 5 Ivana Varekova 2007-11-01 12:30:12 UTC
Thanks. Fixed in busybox-1.7.2-4.fc9.