title: Why doesn't Python exit from a raised exception when executed with an absolute path?
body: <p>SOLVED: Rebooting the machine appears to have removed the issue.  I will update if the problem returns.</p>
  
  <p>I'm having an issue where <code>Python2.6</code> hangs after an exception is raised, specifically when <code>foo.py</code> is called with an absolute path (<code>/home/user/bar/foo.py</code>).  I am then required to <code>ctrl+c</code> out of the program.  If called from within the <code>bar</code> directory as <code>./foo.py</code> or from the root directory as <code>./home/user/bar/foo.py</code>, the program terminates correctly.</p>
  
  <p>foo.py:</p>
  
  <pre><code>#!/usr/bin/env python2.6
  print 'begin'
  x = [0, 1, undefined]
  print 'x'
  </code></pre>
  
  <p>or</p>
  
  <pre><code>#!/usr/bin/env python2.6
  print 'begin'
  raise Exception('stopping here')
  </code></pre>
  
  <p>I may also mention that a <code>sys.exit()</code> works fine, without issues.</p>
  
  <pre><code>#!/usr/bin/env python2.6
  import sys
  print 'begin'
  sys.exit(0)
  </code></pre>
  
  <p>What is happening to the exception that is failing to terminate the program?  This is likely specific to my configuration.  Where should I begin looking for a solution?</p>
  
  <p>EDIT:  <code>execfile('/home/user/bar/foo.py')</code> works fine if running interactive mode.  Additionally, running <code>nohup /home/user/bar/foo.py &amp;</code> results in a hanging process that must be killed.</p>
  
  <p>Running CentOS release 6.3 (Final).  This issue did not always exist.  This only started about a month ago over a weekend (I was not using the machine at that time).</p>
  
  <p>UPDATE: Debugging with GDB, the backtrace points to <code>libpthread.so.0</code>. </p>
  
  <pre><code>#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 ()
  </code></pre>
  
  <p>Anybody know what this means?</p>