¿Por qué Python no sale de una excepción generada cuando se ejecuta con una ruta absoluta?

SOLUCIONADO: al reiniciar la máquina parece haberse eliminado el problema. Voy a actualizar si el problema vuelve.

Tengo un problema en el que Python2.6 bloquea después de que se Python2.6 una excepción, específicamente cuando se llama a foo.py con una ruta absoluta ( /home/user/bar/foo.py ). Entonces estoy obligado a ctrl+c fuera del progtwig. Si se llama desde dentro del directorio de la bar como ./foo.py o desde el directorio raíz como ./home/user/bar/foo.py , el progtwig termina correctamente.

foo.py:

 #!/usr/bin/env python2.6 print 'begin' x = [0, 1, undefined] print 'x' 

o

 #!/usr/bin/env python2.6 print 'begin' raise Exception('stopping here') 

También puedo mencionar que un sys.exit() funciona bien, sin problemas.

 #!/usr/bin/env python2.6 import sys print 'begin' sys.exit(0) 

¿Qué está sucediendo con la excepción que no puede terminar el progtwig? Esto es probablemente específico para mi configuración. ¿Dónde debo empezar a buscar una solución?

EDIT: execfile('/home/user/bar/foo.py') funciona bien si se ejecuta el modo interactivo. Además, ejecutar nohup /home/user/bar/foo.py & da como resultado un proceso de nohup /home/user/bar/foo.py & que debe nohup /home/user/bar/foo.py & .

Ejecución de la versión 6.3 de CentOS (final). Este problema no siempre existió. Esto solo comenzó hace aproximadamente un mes durante un fin de semana (no estaba usando la máquina en ese momento).

ACTUALIZACIÓN: depurando con GDB, el backtrace apunta a libpthread.so.0 .

 #0 0x000000364340e890 in __connect_nocancel () from /lib64/libpthread.so.0 #1 0x00007ffff18960d8 in ?? () from /usr/lib64/python2.6/lib-dynload/_socketmodule.so #2 0x00007ffff189815c in ?? () from /usr/lib64/python2.6/lib-dynload/_socketmodule.so #3 0x00007ffff7d0a706 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #4 0x00007ffff7d0c797 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #5 0x00007ffff7d0abe4 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #6 0x00007ffff7d0bccf in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #7 0x00007ffff7d0bccf in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 #8 0x00007ffff7d0c797 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 #9 0x00007ffff7c9adb0 in ?? () from /usr/lib64/libpython2.6.so.1.0 #10 0x00007ffff7c70303 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0 #11 0x00007ffff7d04dd3 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0 #12 0x00007ffff7d28cd2 in PyErr_PrintEx () from /usr/lib64/libpython2.6.so.1.0 #13 0x00007ffff7d29297 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0 #14 0x00007ffff7d35c32 in Py_Main () from /usr/lib64/libpython2.6.so.1.0 #15 0x000000364281ecdd in __libc_start_main () from /lib64/libc.so.6 #16 0x0000000000400649 in _start () 

¿Alguien sabe lo que esto significa?

Este problema exacto me ha estado mordiendo por un tiempo ahora en una máquina RHEL 6. En ciertos casos, las excepciones causan un locking. De hecho, pude tomar su código literalmente y reproducir el síntoma.

Gracias a la respuesta abrtd, determiné que se instaló el paquete abrt-addon-python, que coloca abrt_exception_handler.py en la ubicación de los paquetes de sitio, y se llama durante el inicio de python. Este archivo anula la función sys.excepthook que se pone en contacto con el demonio abrt mediante sockets. Ver el documento del proyecto ABRT para más información.

Verifiqué que agregar -S a la invocación de python evita el locking. Sin embargo, esta no es una buena solución, ya que la opción -S evita que TODOS los paquetes de sitios se importen en el inicio.

Una mejor solución es agregar lo siguiente en tu código de python:

 import sys sys.excepthook = sys.__excepthook__ 

que restaura el gancho de excepción original y evita el locking.

  • por favor inspeccione sys.path para directorios no absolutos.
  • siempre puedes entrar en él con un depurador, por ejemplo, gdb
  • a veces tengo cosas en PYTHONSTARTUP , lo que hace que el intérprete interactivo haga algo diferente …
  • strace puede ser tu amigo
  • Reinicie la máquina.

Inclinándome ante las gracias del todopoderoso administrador, pude reiniciar la máquina. Todo está bien. Voy a actualizar la pregunta si el problema vuelve.

He rastreado este problema hacia abajo. Está intentando escribir en un socket que se mantuvo abierto por abrtd.

Reiniciando abrtd ‘solucionado’ el problema. Es por esto que el reinicio de la máquina funcionó. Sin embargo, no he encontrado la causa raíz del problema.