This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: python subprocess hangs if script called from another directory
Type: behavior Stage:
Components: None Versions: Python 2.7
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: Massimo.Paladin, dmalcolm, vstinner
Priority: normal Keywords:

Created on 2012-02-22 22:00 by Massimo.Paladin, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (9)
msg153994 - (view) Author: Massimo Paladin (Massimo.Paladin) Date: 2012-02-22 22:00
Here is the behavior I am getting only on Python 2.7.2 in a Fedora 16:
$ cat /tmp/example.py
from subprocess import Popen,PIPE
args = "whatever program".split()
p = Popen(args)

If I run the program with:
$ cd /tmp/; python example.py

I get following as expected
Traceback (most recent call last):
  File "example.py", line 7, in <module>
    p = Popen(args)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

Instead if I run the program with:
$ cd ~; python /tmp/example.py

It hangs until I stop it with ctrl-c

On the same machine python 3.2.1 works fine.
On a mac with python 2.7.1 works fine.
On a rhel5 with python 2.4 works fine too.
msg153995 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-02-22 22:03
I'm unable to reproduce the problem on Fedora 16 with Python 2.7.2.

> It hangs until I stop it with ctrl-c

Do you get an exception after hiting CTRL+c?
msg153996 - (view) Author: Massimo Paladin (Massimo.Paladin) Date: 2012-02-22 22:05
Yes, the expected one:

^CTraceback (most recent call last):
  File "/tmp/example.py", line 7, in <module>
    p = Popen(args)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
msg153997 - (view) Author: Massimo Paladin (Massimo.Paladin) Date: 2012-02-22 22:08
The line which is mentioned in the exception for the file example.py is 7 because I have something commented out which I didn't past in the text before.
msg153998 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-02-22 22:08
Could you try to collect more information with gdb?

cd ~; gdb -args python /tmp/example.py
(gdb) run
<python hangs>
CTRL+c
(gdb) where
<the expected output>
msg154001 - (view) Author: Massimo Paladin (Massimo.Paladin) Date: 2012-02-22 22:12
$ cd ~; gdb -args python /tmp/example.py
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.7.2-5.2.fc16.x86_64
(gdb) run
Starting program: /usr/bin/python /tmp/example.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 16202.
^C
Program received signal SIGINT, Interrupt.
0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
(gdb) where
#0  0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
#1  0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#2  0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
#3  0x00000039d6ae00bd in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#4  0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#5  0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#6  0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007ffff0755597 in ?? () from /usr/lib64/python2.7/lib-dynload/_functoolsmodule.so
#8  0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#9  0x00000039d6ade795 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#11 0x00000039d6ae0580 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#12 0x00000039d6ae15a5 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#13 0x00000039d6a6dc2c in ?? () from /usr/lib64/libpython2.7.so.1.0
#14 0x00000039d6a49193 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#15 0x00000039d6ada457 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#16 0x00000039d6afcdde in PyErr_PrintEx () from /usr/lib64/libpython2.7.so.1.0
#17 0x00000039d6afd38e in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#18 0x00000039d6b0e745 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#19 0x00000039d362169d in __libc_start_main () from /lib64/libc.so.6
#20 0x0000000000400651 in _start ()
(gdb)
msg154007 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-02-22 23:09
> (gdb) where
> #0  0x00000039d3a0e8e0 in __connect_nocancel () from /lib64/libpthread.so.0
> #1  0x00007ffff095c678 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so
> #2  0x00007ffff095d524 in ?? () from /usr/lib64/python2.7/lib-dynload/_socketmodule.so

Hum, it's something related to network. Fedora uses its ABRT program
to catch program failures.

/usr/lib/python2.7/site-packages/abrt.pth contains "import
abrt_exception_handler" which install a custom sys.excepthook. This
hook writes a report and send it to the UNIX socket
/var/run/abrt/abrt.socket.

In your example, it looks like the abrt daemon is dead or at least
doesn't not answer, and so the abrt "client" hangs on the connection
to the UNIX socket. You may try to add a timeout to
s.connect("/var/run" + "/abrt/abrt.socket") in write_dump() of the
abrt_exception_handler module. You should also report the bug to
Fedora because it's unrelated to Python (core).
msg154061 - (view) Author: Massimo Paladin (Massimo.Paladin) Date: 2012-02-23 12:21
Will follow it.

Thanks,
-Massimo
msg154088 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-02-23 20:26
> Will follow it.

If you report the issue to abrt, could you give me the url to your report please? (as a comment to this issue)
History
Date User Action Args
2022-04-11 14:57:27adminsetgithub: 58299
2012-02-23 20:26:06vstinnersetmessages: + msg154088
2012-02-23 12:21:54Massimo.Paladinsetstatus: open -> closed
resolution: works for me
messages: + msg154061
2012-02-22 23:09:37vstinnersetnosy: + dmalcolm
2012-02-22 23:09:03vstinnersetmessages: + msg154007
2012-02-22 22:12:06Massimo.Paladinsetmessages: + msg154001
2012-02-22 22:08:50vstinnersetmessages: + msg153998
2012-02-22 22:08:07Massimo.Paladinsetmessages: + msg153997
2012-02-22 22:05:28Massimo.Paladinsetmessages: + msg153996
2012-02-22 22:03:21vstinnersetnosy: + vstinner
messages: + msg153995
2012-02-22 22:00:03Massimo.Paladincreate