Skip to content
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

Ctrl+C does not kill gcc #4443

Closed
msarahan opened this issue Jan 27, 2017 · 11 comments
Closed

Ctrl+C does not kill gcc #4443

msarahan opened this issue Jan 27, 2017 · 11 comments
Labels
locked [bot] locked due to inactivity
Milestone

Comments

@msarahan
Copy link
Contributor

@sscherfke commented on Fri Jan 27 2017

If I build a C-lib with conda-build, I can no longer cancel the build using Ctrl-C. Conda itself will die, but the compiler processes will continue to run. It looks like the signals are not (or no longer) forwared to all sub processes.

$ conda info
Current conda install:

               platform : linux-64
          conda version : 4.3.8
       conda is private : False
      conda-env version : 4.3.8
    conda-build version : 2.1.2
         python version : 3.6.0.final.0
       requests version : 2.12.5
             user-agent : conda/4.3.8 requests/2.12.5 CPython/3.6.0 Linux/4.8.15-200.fc24.x86_64 Fedora/24 glibc/2.23

@msarahan commented on Fri Jan 27 2017

Confirmed. Switching to conda 4.2.x fixes it for me. Leaving this issue here until I can isolate it further.

@msarahan
Copy link
Contributor Author

Copied from conda-build. I'm not sure yet whether this is a bug in conda or conda-build. In my searches through conda's code, there were no changes to code involving KeyboardInterrupt between 4.2.x and 4.3.x. Still, this bug is present with conda 4.3.x and not 4.2.x, so it seems to be some exception swallowing added in 4.3.x.

@kalefranz
Copy link
Contributor

kalefranz commented Jan 27, 2017

Yes, there's a signal handler in 4.3. It's invoked and registered anytime logging is also configured.

https://github.com/conda/conda/blob/4.3.x/conda/gateways/signals.py
https://github.com/conda/conda/blob/4.3.x/conda/gateways/__init__.py

I've created a pull request to handle signal forwarding better: #4447

I've based what I'm doing in the PR on advice from http://stackoverflow.com/questions/13593223/making-sure-a-python-script-with-subprocesses-dies-on-sigint

@kalefranz kalefranz added this to the 4.3 milestone Jan 27, 2017
@sscherfke
Copy link
Contributor

Is this fixed in 4.3.9? It looks like #4447 landed in that version.

@msarahan
Copy link
Contributor Author

@kalefranz this is still an issue with conda 4.3.11. I don't understand your response, though - is this something you're working on fixing in conda, or is it like logging where it needs some fix on the conda-build side too?

@msarahan
Copy link
Contributor Author

@kalefranz can you please update this issue with current status? I've just received a report from Samsung that they are using the latest conda from canary and are still seeing this issue.

@kalefranz
Copy link
Contributor

Full history of this issue can be tracked from #5133 (comment) I think. There's also #5135.

The only reason conda needs to deal with signal handlers at all is to be able to attempt a rollback during an install transaction if a signal is sent mid-transaction.

I've spent time with http://stackoverflow.com/questions/13593223/making-sure-a-python-script-with-subprocesses-dies-on-sigint and implemented pretty much every suggestion in there. If anybody has any more ideas, please share!

@kalefranz
Copy link
Contributor

As in that stack overflow link, whenever conda-build subprocesses, it should also be sure it's forwarding signals to child processes, apparently by setting stdin as PIPE.

@kalefranz
Copy link
Contributor

conda-build is also free to use conda.exports.subprocess_call that implements all those suggestions in that stackoverflow comment.

https://github.com/conda/conda/blob/master/conda/gateways/subprocess.py#L38-L60

@kalefranz
Copy link
Contributor

@msarahan Have we made progress on this at all in recent versions of conda? Do you feel like it's getting better at least?

@kalefranz
Copy link
Contributor

I'm going to close this issue for now. For the conda-build case in particular, I think it should mostly be solved with registering signal handlers only right before executing unlink-link transactions, and the deregistering them afterward. In the initial implementation for signal handling, conda registered signal handlers on import, and then kept them registered.

@github-actions
Copy link

Hi there, thank you for your contribution to Conda!

This issue has been automatically locked since it has not had recent activity after it was closed.

Please open a new issue if needed.

@github-actions github-actions bot added the locked [bot] locked due to inactivity label Oct 11, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity
Projects
None yet
Development

No branches or pull requests

3 participants