-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
[Bug] CKAN process ignores termination signals while downloading/updating #3423
Comments
This comment has been minimized.
This comment has been minimized.
I'm referring to the GUI, I haven't tried from the command line. I mean when the GUI client fires up, the first thing it does is refresh/update mod header info from the repos I assume. It is during that first refresh/update upon startup that I am referring. I do know that long, long ago Linux had some corners where it would block on network timeouts or something This report does not apply to the command line client. I don't know what happens there. I only use the GUI and forget the command line client even exists, sorry about that |
Thanks for the clarification. Still very weird; I'm able to terminate the CKAN GUI via ctrl-C even while updating the registry. Where is the window focus when you press ctrl-C? It's not going to try to stop the process if CKAN has focus, for a GUI app ctrl-C just means copy. You'd need to run ckan from a terminal and press ctrl-C while that terminal has focus. |
Typically I use the r-click on the process icon in panel, then click 'close'. From what I understand, this sends a SIGTERM. It works on KSP for example when I bail on loading the program in mid load, or when it is hung up. In the past I've used "killall -TERM ckan.exe" with no effect. I wonder if the linux network timeout thing is still alive and breathing in the linux kernel? Basically network i/o had so much priority it effectively blocked until timeout for the process waiting on traffic or something similar to that. Don't quote me on that, but it was similar to that. Let me play with it a bit over the next few days. I always have instances of bad wifi |
OK, from what I can tell ctrl-C sends
That may be because the actual command is
You could try |
I was going by memory. I tried the killall first, realized it was a mono process, grabbed the PID, the just did a kill for that PID. This was a awhile ago though. So block, if not grain of salt. I'll dig more into it and close this if I can't get any further |
Looks like we're at a dead end here; the reported problem doesn't happen as far as I can tell, and we don't have a clear replacement description. @mgalyean if you can figure out what you were seeing, please let us know and we can re-open this for investigation. |
Background
Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
N/A
Problem
Once CKAN has started updating its info, it is not possible to terminate it via r-click->close or ctrl-c. So if you are on a really slow wifi and want to switch to a faster one you have to wait for CKAN to timeout on the network, then exit it, then connect to the faster wifi, then relaunch CKAN. It doesn't appear to want to attempt to retry the update without exiting first even after the better connection is established. There could be two issues here: no network retry after timeout under some vague condition and 2) all processes should be interruptible; if a critical atomic data operation is in process, it should be rolled back either prior to exiting, or rolled back by the restarted process
Steps to reproduce
Try to interrupt/close/ctrl-c/kill -TERM while it is updating right after opening
It won't stop until network timeout
Expected behavior
Stops when told to stop. Doesn't ignore user input or signals until a network timeout occurs
The text was updated successfully, but these errors were encountered: