Reproduced on rhel-8.2 with gcc-toolset-9-strace-5.1-4.el8.

+++ This bug was initially created as a clone of Bug #1725113 +++

+++ This bug was initially created as a clone of Bug #1035434 +++

Reproduced on RHEL-7 with

strace-4.8-3.el7
kernel-3.10.0-23.el7

+++ This bug was initially created as a clone of Bug #1035433 +++

Description of problem:
When using strace to debug an LXC problem I noticed that it gets a bit confused by PID namespaces.

I am running strace from host context, so I expect all PIDs it reports to be host PIDs. When strace creates new log files (due to the -ff CLI option) it names them based on the host PIDs, which is good. Inside these log files though the clone() syscalls are reporting container PIDs which is bad. This means you can't correlate the clone() syscalls  with the log files strace is creating.

If running strace from inside container context it correctly uses container PIDs in both places.

Version-Release number of selected component (if applicable):
strace-4.8-1.fc19.x86_64
kernel-3.11.9-200.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1. From the host run

# strace -f -ff -o s.log unshare --pid -- /bin/sh

and at the shell prompt execute '/bin/sh' again. Then do it again. And again.. Then exit back to the host context

You should now have several log files
 

Actual results:
# ls s.log.*
s.log.9851  s.log.9860  s.log.9861  s.log.9862
# grep clone s.log.98*
s.log.9851:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe81e7b6a10) = 9860
s.log.9860:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f47d93aca10) = 2
s.log.9861:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9962d34a10) = 3


Expected results:
# ls s.log.*
s.log.9851  s.log.9860  s.log.9861  s.log.9862
# grep clone s.log.98*
s.log.9851:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fe81e7b6a10) = 9860
s.log.9860:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f47d93aca10) = 9861
s.log.9861:clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9962d34a10) = 9862


Additional info:

--- Additional comment from Eugene Syromiatnikov on 2019-03-11 13:10:46 UTC ---

It's unlikely that I'll be able to push the required changes to upstream during 7.7 development time frame, moving to 7.8.

--- Additional comment from Eugene Syromiatnikov on 2019-06-28 13:11:41 UTC ---

Private comments from the cloned bug:

--- Additional comment from RHEL Product and Program Management on 2013-11-27 18:45:22 UTC ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Jeff Law on 2013-11-27 19:01:01 UTC ---

Not getting into RHEL 7.0 unless it's addressed upstream.

--- Additional comment from RHEL Product and Program Management on 2013-11-27 19:26:25 UTC ---

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

--- Additional comment from Daniel Berrange on 2013-11-27 19:36:09 UTC ---

Don't set dev-ack==- because the stupid bot just closes bugs when you do that. If it isn't feasible for 7.0 just move it to 7.1

--- Additional comment from Jeff Law on 2013-12-09 22:48:39 UTC ---

But you can't change it to 7.1 (dropdown doesn't exist) and there's very little chance we'll tackle this internally.   Take it upstream, please.

--- Additional comment from Matt Newsome on 2013-12-13 11:37:39 UTC ---

(In reply to Daniel Berrange from comment #4)
> Don't set dev-ack==- because the stupid bot just closes bugs when you do
> that. If it isn't feasible for 7.0 just move it to 7.1

Daniel, I've changed this to rhel-7.1? but condnak upstream. Once you've created the upstream bug, please link it here. For clarity, we will not be working on this without an upstream bug, but we'll leave this RH BZ open so RH QE can verify the fix if it happens.

We'll review again at 7.1 planning and if it's not nak'd upstream, we'll close this one out then.

--- Additional comment from Ludek Smid on 2014-04-23 17:10:47 UTC ---

Since the release flag was set to ? after the pm_ack flag was set to + (was likely set for the previous release), the pm_ack flag has been reset to ? by the bugbot (pm-rhel). This action ensures the proper review by Product Management.

--- Additional comment from Matt Newsome on 2015-12-21 18:54:10 UTC ---

Moving manually for consideration at 7.3 planning. This is not a guarantee that this BZ will be fixed in that release.

--- Additional comment from Matt Newsome on 2016-08-01 16:25:00 UTC ---

strace did not make the agreed ACL components for 7.3.

Moving manually for consideration at 7.4 planning. This is not a guarantee that this BZ will be fixed in that release.

--- Additional comment from DJ Delorie on 2017-02-21 19:26:43 UTC ---

No upstream fix yet.

Moving manually for consideration at 7.5 planning. This is not a guarantee that this BZ will be fixed in that release.

--- Additional comment from Jeff Law on 2017-07-18 18:14:29 UTC ---

No upstream movement, deferring again.

--- Additional comment from DJ Delorie on 2018-04-06 21:44:43 UTC ---

Still no upstream movement, deferring again.

--- Additional comment from Edjunior Barbosa Machado on 2020-01-14 10:57:55 UTC ---

Reproduced on RHEL-8.2 with:

strace-4.24-6.el8
kernel 4.18.0-159.el8
RHEL-8.2.0-20191203.0

https://beaker.engineering.redhat.com/tasks/executed?task=%2Ftools%2Fstrace%2FRegression%2Fbz1035434-strace-gets-confused-by-PID-namespaces&job_id=3935677&job_id=3936292

--- Additional comment from Edjunior Barbosa Machado on 2020-01-14 10:58:30 UTC ---