Bug 1725113

Summary: [RHEL 8] strace gets confused by PID namespaces
Product: Red Hat Enterprise Linux 8 Reporter: Eugene Syromiatnikov <esyr>
Component: straceAssignee: Eugene Syromiatnikov <esyr>
strace sub component: system-version QA Contact: Edjunior Barbosa Machado <emachado>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: unspecified CC: berrange, emachado, esyr, lmiksik, mcermak, mjw, mnewsome, mpetlan, ohudlick, skozina
Version: ---Keywords: Reopened
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: strace-5.7-2.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1035434
: 1790836 (view as bug list) Environment:
Last Closed: 2021-05-18 13:28:15 UTC Type: Bug
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: 1035434, 1780592, 1804334, 1807458    
Bug Blocks: 1790836, 1884555, 1894575    

Description Eugene Syromiatnikov 2019-06-28 13:09:48 UTC
+++ 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.

Comment 3 Edjunior Barbosa Machado 2020-01-14 10:58:30 UTC
*** Bug 1780592 has been marked as a duplicate of this bug. ***

Comment 13 errata-xmlrpc 2021-05-18 13:28:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (strace bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2021:1573