Bug 467652
| Summary: | Systemtap regression "-c" doesn't allow for shell redirection. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Wade Mealing <wmealing> |
| Component: | systemtap | Assignee: | Frank Ch. Eigler <fche> |
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | CC: | cward, dsmith, ebachalo, ltroan, mjw, moshiro, pmuller, syeghiay, tao |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-20 21:06:50 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 468087 | ||
|
Description
Wade Mealing
2008-10-20 01:38:45 UTC
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.
(Sorry, omit the "If a full $SHELL is run," from above.) Is the above explanation sufficient to understand why the behavior changed? 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 issue 229712 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. 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 #10 From Frank Ch. Eigler (fche) 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) 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. The following patch has been added to the spec file for this issue: systemtap-0.7.2-allow-shell-redirection.patch 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 |