Python won't exit when called with absolute pa

Question

I have some python scripts that run via cron, and they no longer exit correctly when the script is called with an absolute path. They will hang until the process is terminated. I believe it happened after I moved /var and /home to a different partition.

I checked into the environment variables and couldn't see anything obviously wrong, this happens either when run with cron or a bash subshell, but not when run directly.

If I run it as a subshell it hangs until I kill it (ctrl-c) and then gives me the output.

[wotstats@rock test]$ echo 'assert 0==1, "fails"' > test.py
[wotstats@rock test]$ /bin/bash -c "/usr/bin/python /var/home/wotstats/test/test.py"
^CTraceback (most recent call last):
  File "/var/home/wotstats/test/test.py", line 1, in <module>
    assert 0==1, "fails"
AssertionError: fails

If I don't call a script it terminates as expected without hanging:

[wotstats@rock test]$ /bin/bash -c "echo 'assert 0==1, \"fails\"' | /usr/bin/python"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AssertionError: fails

I do get an immediate log error when the exception occurs:

Dec  9 13:33:44 rock abrt: detected unhandled Python exception in '/var/home/wotstats/test/test.py'

I ran some tests based on the input, and found that this problem occurs even when called as /test.py and when run as root. I also tried /root and /usr with the same effect.

Similar or same question was asked here and resolved by reboot; I'd rather figure it out and avoid the reboot if I can.

Answer 1

Instead of:

/usr/bin/python /var/home/wotstats/test/test.py

use:

cd /var/home/wotstats/test/
/usr/bin/python test.py<br/>

Answer 2

Ok, got it figured out. Thanks for the help.

I ran an strace and found that it was hanging on the following:

socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path="/var/run/abrt/abrt.socket"}, 27^C
<unfinished ...>

That led to Bugzilla which indicated that SELinux was the problem. I had already changed SELinux to permissive mode (I screwed it up moving /var), but had not restarted abrtd.

Restarting the abrtd service resolved the problem.