Description of problem: There is a need to translate exit status of traced process to strace caller. I'd like to propose new option -k for that purpose. Version-Release number of selected component (if applicable): 4.4.99 How to test: $ strace /bin/false 2>/dev/null; echo rc=$? rc=0 $ strace /bin/true 2>/dev/null; echo rc=$? rc=0 $ strace -k /bin/false 2>/dev/null; echo rc=$? rc=1 $ strace -k /bin/true 2>/dev/null; echo rc=$? rc=0
Created attachment 94716 [details] proposed patch
One problem with this interface is that strace getting an error itself will still pollute the return value of the program.
Is there any better approach?
Created attachment 96530 [details] proposed patch rediffed for strace-4.5.1, without coredump trace feature.
Created attachment 115496 [details] strace-4.5.12-alt-keep_status.patch Rediffed for new strace version.
I'd like to support Dmitry's proposal. I run strace to know what files an application accesses that I only have as a binary. It works great! Unfortunately it does not give me an indication of the program's return value. So I have to parse strace's output for that which is error prone. Roland, its okay if we return failure if either program or strace fail. As the caller I can still output a reasonable error message.
*** Bug 163613 has been marked as a duplicate of this bug. ***
Created attachment 117548 [details] strace-4.5.13-alt-keep_status.patch Rediffed for strace-4.5.13.
Created attachment 123341 [details] strace-4.5.14-alt-keep_status.patch Rediffed for strace-4.5.14
Please post on the ml, I think this can go in now. No reason to conditionalize setting "return_code". I think I'd like to see all other existing exit calls changed to exit(failure_code) and then under -k we might set failure_code to 128 or something. That way strace having an error is easier to distinguish from the likely exit codes of a traced process (such as 1 or 2).
Dedicated exit code 128 in "-k" mode is OK for me.
(In reply to comment #10) > Please post on the ml, I think this can go in now. > No reason to conditionalize setting "return_code". > > I think I'd like to see all other existing exit calls changed to > exit(failure_code) and then under -k we might set failure_code to 128 or > something. That way strace having an error is easier to distinguish from the > likely exit codes of a traced process (such as 1 or 2). Hi Roland, Should the status of this bug be changed as result of the ML discussion or any subsequent work? Thanks, John
Not to be meant as a criticism, but just a thought: passing back the exit code is a good idea, but sometimes it is not enough. For example, when parent process is normally sending signals to child, it breaks when you run child under strace. Imagine that parent listens on a socekt and starts children for new connections: $ parent 1.2.3.4:56 -e child arg1 arg1 If you run it like $ parent 1.2.3.4:56 -e strace child arg1 arg1 , attempts to send signals between parent and child would not work as intended. The nice thing to have would be an option for strace to fork, and exec traced child in *parent*, not child. Then child attaches to parent similarly to strace -p PID. But of course this goes far beyond this bug.
Created attachment 317603 [details] Patch: exit/kill ourself with straced child's exitcode/signal Apparently discussion on mailing list died out with no results. I propose this patch. It just makes strace exit with child's exitcode. Rationale: I think in real-world usage people do not check strace usage in scripts. They just use it correctly, so that it doesn't exit(1) with usage info and whatnot. But know for a fact that when I try to debug something by replacing "cmd [args]" with "strace cmd [args]" the fact that parent does not see exit code of cmd but seels zero, always, sometimes is a problem. IOW: I do not think that there are users who will be adversely affected by this change in behavior. Therefore I do not think adding a switch to enable this is worth it. It will be just a case of featuritis. Problems this patch fixes compared to previous patches: * strace returns exit code of straced process, *never its children*. * If child died from a signal, strace will (try to) die from the same signal. * strace -p <pid> is not affected (will exit 0 as before).
(In reply to comment #14) > Created an attachment (id=317603) [details] > Patch: exit/kill ourself with straced child's exitcode/signal I think your idea how to implement this RFE is better than mine. I tested it and have no compatibility problems so far. I'm OK to install your patch with minor cleanup.
Created attachment 318019 [details] strace-4.5.18-exit.patch Proposed patch (patch by Denys Vlasenko with minor cleanup).
in comment #10 Roland said "changed to exit(failure_code)", so what about using the EXIT_FAILURE as per stdlib.h as opposed to hardcoding it? Minor nit..
strace-4.5.19-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/strace-4.5.19-1.fc10
strace-4.5.19-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/strace-4.5.19-1.fc11
strace-4.5.19-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update strace'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-10733
strace-4.5.19-1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update strace'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10843
strace-4.5.19-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
strace-4.5.19-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.