New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Close background process if IDLE closes abnormally. #58645
Comments
Now if IDLE was ran from console and then terminated by <Ctrl-\> or kill signal — background process keep living forever. That process have to stop itself if there are no frontend IDLE. |
You need to specify os (with version) *nix? |
I use Ubuntu Linux 11.10 Hmm, you are right: background process dies. But I'm pretty sure when I worked on IDLE bugs three weeks ago sometimes that process remained to live forever. Aahh. |
I can confirm this problem with Ubuntu 11.04. |
Andrew: I strongly agree with the goal that IDLE should not leave zombie processes. The background process should die if either 1) IDLE restarts the shell with a new background process, as with every edit-run cycle, or 2) IDLE dies. The desired behavior seems to be both somewhat fragile and system dependent. I do not know whether 100% compliance on every system is sensibly possible. The issue I referred to is bpo-12540. The problem there was worse: leaving a zombie for every shell restart on Windows. Perhaps the discussion there will give you some ideas. Ctrl-\ does not seem to do anything on Windows. I do not know whether TaskManager 'Terminate process' corresponds to *nix SIGTERM, SIGQUIT, SIGKILL, something else, or is completely Windows specific. |
Terry, sorry. That's definitely posix-specific bug. I'll make a patch assuming Windows works well with killing IDLE. To be polite I'll describe used signal names shortly. SIGKILL, SIGTERM, SIGINT and SIGQUIT are used to stop process. |
Just a bit more info: ^D and ^\ in Command Prompt interpreter print '^D' or '^\'. Return causes syntax error. ^Z\n in interpreter causes silent close. (Because DOS used ^Z as end-of-file.) ^D in IDLE causes silent close. IDLE ignores ^\ and ^Z both -- nothing printed or stored. Following \n gets prompt back. The difference is not nice for Windows users, but I presume IDLE behavior is same as on *nix and consider consistency across platforms good and should be kept. If I understand, IDLE needs to install a SIGQUIT handler to terminate the background process 'resource'. That should work on Windows too as either SIGQUIT will never happens, or if it does, same should happen on Windows too. I know SIGKILL cannot be caught. What about SIGTERM? |
We can install signal handlers for everything what can stop process but I prefer to pass IDLE pid to subintepreter and periodically check for prime process existing. |
This bug is related to bpo-12540. The approach taken there is to have the IDLE frontend explicitly kill the subprocess. It's a band-aid to the problem that run.py doesn't exit when the socket to the IDLE frontend closes (either by shell restart or kill -9 on IDLE). Attached is a patch to cause the subprocess to exit. I have to admit not fully understanding why it works (on Ubuntu 11.04). It looks like the following code in _getresponse() in rpc.py is what keeps the subprocess running: cvar.acquire()
while myseq not in self.responses:
cvar.wait() I also tried disabling the "terminate_subprocess" in PyShell.py. With that change, the subprocess does not terminate on a shell restart (unless my patch is applied). Andrew, Terry: What are your thoughts? |
I still prefer to check in subprocess for parent proc existing. |
Andrew, the reason the subprocess is not closing is due to a thread management problem. I found that a dummy thread handles cvar.wait() which is why the subprocess fails to terminate properly. If you change the tight loop in _getresponse to be: while myseq not in self.responses:
print(threading.enumerate(), file=sys.__stderr__)
sys.__stderr__.flush()
cvar.wait(1) Then you'll get the following dumped to the terminal once a second: The MainThread already stopped, but these two daemon threads don't terminate, which is strange. Is this a bug in itself? Polling the OS for the IDLE frontend process will give an indication to terminate the subprocess, but actually terminating the subprocess from within the subprocess is the main problem. Attached is a patch which takes a different approach to terminating the subprocess by using .shutdown instead. |
outdated |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: