On Tue, 15 Mar 2022 at 08:28, Dan Stromberg <drsali...@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@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@celery_worker:/app$ bg
> [1]+ strace -f -s 1024 -o /tmp/t.strace /tmp/t &
> tact@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@celery_worker:/app$ fg
> bash: fg: job has terminated
> [1]+  Done                    strace -f -s 1024 -o /tmp/t.strace /tmp/t
> tact@celery_worker:/app$ grep execve /tmp/t.strace
> 1366  execve("/tmp/t", ["/tmp/t"], 0x7ffd89f9c3b8 /* 49 vars */) = 0
> tact@celery_worker:/app$
>
> I've deleted some irrelevant processes from the 'ps axf'.
>
> /tmp/t is actually just:
> tact@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
-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to