Weird strace of #! python script

Dan Stromberg drsalists at
Tue Mar 15 00:00:17 UTC 2022

On Mon, Mar 14, 2022 at 3:23 PM Eugene Syromyatnikov <evgsyr at>

> On Mon, Mar 14, 2022 at 10:37 PM Dan Stromberg <drsalists at>
> wrote:
> > So anyway, I'm strace'ing a #!/usr/bin/python2 script.
> >
> > I expected to see an exec of /usr/bin/python2, but I don't.  I just see
> an
> > exec of /tmp/t.
> Why, exactly, did you expect that? strace doesn't parse binary
> supplied as a command (or runs a shell to do so), it just executes it
> (as stated in the NOTES section in the man page[0]). The parsing of
> the interpreter is performed in-kernel by the binfmt_script loader[1]
> (along with all its limitations like interpreter command line size and
> single argument only).

I thought I had seen a second exec for a #! script, but perhaps I was

> > Was this some sort of security feature I never heard about?  I'm tracing
> a
> > very simple time.sleep(10) here, but the same thing is (not) happening
> in a
> > larger script that I need to track down a bug in.
> Is that script run in a shell? That would explain it.
The larger script is clone'd and execve'd by a C++ program.

It's possible I collected the strace outputs too soon, but I see another
Python program logging messages that don't show up in the strace.

> > Is there a way I can coax Linux and/or strace to show all the exec's,
> like
> > they used to?
> All executed execve() calls are shown.
That's good to hear.

> > what else is missing from the strace report.
> syscalls performed by the child process before the first
> execv/execve/execveat call are not shown, but they usually not
> pertaining to the trace, see TCB_HIDE_LOG/hide_log() usage[2][3].
> [0]
> [1]
> [2]
> [3]
OK.  Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Strace-devel mailing list