Bug 467652 - Systemtap regression "-c" doesn't allow for shell redirection.
Systemtap regression "-c" doesn't allow for shell redirection.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: systemtap (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Frank Ch. Eigler
BaseOS QE
:
Depends On:
Blocks: 468087
  Show dependency treegraph
 
Reported: 2008-10-19 21:38 EDT by Wade Mealing
Modified: 2010-10-23 01:17 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:06:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wade Mealing 2008-10-19 21:38:45 EDT
Description of problem:

stap command fails when a command which includes a redirection is specified.

For example:
# stap -c "ls > log" exit.stp
stapio:start_cmd:130: ERROR: wordexp parsing error: Cannot allocate memory
ptrace detach: No such process

Version-Release number of selected component (if applicable):

Kernel Version: 2.6.18-118.el5
Related Package Version: systemtap-0.7.2-1.el5

How reproducible:

Every time

Steps to Reproduce:
1. Run systemtap with a shell direction in the "-c" option

Actual results:

stapio:start_cmd:130: ERROR: wordexp parsing error: Cannot allocate memory


Expected results:

Shell redirection to work, system to continue.


Additional info:

Frank has already made this error message more useful in the current git release, however the customer wishes this to work the same as it previously did in the 5.0 release.

I could write a patch to create a shell and handle redirection, but I'm not sure that this is the path that should/could be taken for the 5.3 release.
Comment 2 Frank Ch. Eigler 2008-10-20 06:36:36 EDT
Reverting the "stap -c" code to run the equivalent of system() is
going to be difficult, if we wish to retain the new benefits of
fairly clean utrace/uprobe probes applied to such child processes.
If a full $SHELL is run, then probes such as this:

  stap -e 'probe process.syscall { }' -c 'ls'

currently do not list all the activities of the $SHELL too as it
takes its sweet time starting up and finally fork/execing /bin/ls.

Backporting the fix for the wordexp error message would be fine.
Comment 3 Frank Ch. Eigler 2008-10-20 07:11:03 EDT
(Sorry, omit the "If a full $SHELL is run," from above.)
Comment 4 Frank Ch. Eigler 2008-10-20 19:47:05 EDT
Is the above explanation sufficient to understand why the
behavior changed?
Comment 7 Issue Tracker 2008-10-23 10:56:00 EDT
Hi,

Response from FJ:
---
I don't think clean probe is benefit in all case.
To investigate how a command is run, I need to know including shell's
behavior
not only the command. Any command cannot run spontaneously without shell.

For example, when it takes excessive time until a command finishes,
shell might occupy almost all the time. If we don't know the behavior
including shell, we cannot find the cause.
---

Best Regards,
M Oshiro

Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by moshiro@redhat.com 
 issue 229712
Comment 8 Frank Ch. Eigler 2008-10-23 11:24:09 EDT
Thank you, Mr. Oshiro.  I believe the misunderstanding may be that
the new code *no longer uses a shell* to start the command named by
"-c".  Instead, it interprets the command line and directly runs the
the named child process with "execve"-style system calls.  The system(3)
library call is no longer used.  So in this case, there is no shell whose
performance we may need to measure.

If one deliberately wants to analyze some shell's performance, one
can use
%  stap -c 'sh -c "COMMAND"' ....
where the COMMAND string could include redirection, pipes, backgrounded
jobs, and basically whatever that particular shell allows.
Comment 10 Frank Ch. Eigler 2008-10-23 16:34:39 EDT
Please see if the new change implemented in git systemtap
would be an acceptable compromise.

http://sourceware.org/git/?p=systemtap.git;a=commitdiff;h=34f2e0b9b69ddbc2f2e7503e887f16fca9fdfee2
Comment 15 Larry Troan 2008-11-04 08:56:11 EST
>Comment #10 From  Frank Ch. Eigler (fche@redhat.com)  2008-10-23 16:34:39 EDT   
> Please see if the new change implemented in git systemtap
> would be an acceptable compromise.
>
> http://sourceware.org/git/?p=systemtap.git;a=commitdiff;h=34f2e0b9b69ddbc2f2e7503e887f16fca9fdfee2

Comment #13 From  Issue Tracker (tao@redhat.com)  2008-11-04 08:53:29 EDT [edited]

Yes, it is acceptable.
I think it is a better solution though it will be a little bit complex.
It retains a backward compatibility.
Comment 17 David Smith 2008-11-05 10:34:27 EST
The following patch has been added to the spec file for this issue:

systemtap-0.7.2-allow-shell-redirection.patch
Comment 23 errata-xmlrpc 2009-01-20 16:06:50 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0184.html

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