Weird strace of #! python script

[Chris Angelico]

On Tue, 15 Mar 2022 at 08:28, Dan Stromberg <drsalists at gmail.com> wrote:
>
> Hi folks.
>
> First off, I know, python2 is ancient history.  Porting to 3.x is on my
> list of things to do (though I'm afraid it's not yet at the top of the
> list), and the same thing happens with python3.
>
> 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.
>
> As follows:
> tact at celery_worker:/app$ strace -f -s 1024 -o /tmp/t.strace /tmp/t
> ^Z
> [1]+  Stopped                 strace -f -s 1024 -o /tmp/t.strace /tmp/t
> tact at celery_worker:/app$ bg
> [1]+ strace -f -s 1024 -o /tmp/t.strace /tmp/t &
> tact at celery_worker:/app$ ps axf
>   PID TTY      STAT   TIME COMMAND
>  1163 pts/0    Ss     0:00 bash
>  1363 pts/0    S      0:00  \_ strace -f -s 1024 -o /tmp/t.strace /tmp/t
>  1366 pts/0    S      0:00  |   \_ /usr/bin/python2 /tmp/t
>  1367 pts/0    R+     0:00  \_ ps axf
> tact at celery_worker:/app$ fg
> bash: fg: job has terminated
> [1]+  Done                    strace -f -s 1024 -o /tmp/t.strace /tmp/t
> tact at celery_worker:/app$ grep execve /tmp/t.strace
> 1366  execve("/tmp/t", ["/tmp/t"], 0x7ffd89f9c3b8 /* 49 vars */) = 0
> tact at celery_worker:/app$
>
> I've deleted some irrelevant processes from the 'ps axf'.
>
> /tmp/t is actually just:
> tact at celery_worker:/app$ cat /tmp/t
> #!/usr/bin/python2
>
> import time
>
> time.sleep(10)
>
>
> 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 there a way I can coax Linux and/or strace to show all the exec's, like
> they used to?  Not having them makes me wonder what else is missing from
> the strace report.
>
> I'm on a Debian 11.2 system with strace 5.10 and Python 2.7.18.
>
> Thanks!

I'm not sure, but I suspect that strace is skipping the exec into the
process itself. When I try this myself, I can see the trace of the
sleep call itself (it's implemented on top of select()), so it does
seem to be doing the proper trace. My guess is that the shebang is
being handled inside the exec of /tmp/t itself, rather than being a
separate syscall.

In any case, it doesn't seem to be a Python thing; I can trigger the
same phenomenon with other interpreters.

ChrisA