This was not due to solve_disambiguation script. Investigating in that matter, the ^C was not recognized if the async buffer exceeds max_queue_size. This happened because no page was putted to live wiki. I found another hint to the api cache while restarting the script:
Could not load cache: TypeError("'int' object is not iterable)

Very strange but clearing the api_cache folder solves the problem. Maybe pywikibot.async_manager returns None?

Another idea: Maybe it had sth to do with cache implementation of https://gerrit.wikimedia.org/r/#/c/131017/ which was fetched on my repository as I started this script.

Looks like 'async' does the problem:

if 'async' not in kwargs and self.getOption('always'):
    kwargs['async'] = True

Investigating deeper into this issue I found a problem inside BaseBot class:

BaseBot.userPut invokes BaseBot._save_page with parameters page for the page and page.save for the function and **kwargs at last.

Now BaseBot._save_page tries to call the given function:

func(*args, **kwargs)

with should be equal as calling

page.save(*args, **kwargs)

page.save made an async_request with page._safe as function but page._save itself was never reached and there was no exception or message or any other hint to that problem; the task just hangs and couldn't be stopped with ctrl-c. Killing the task was the only way to kill him.

Maybe we should use page_put_queue.get_nowait() or use a timeout parameter for page_put_queue.get() in async_manager?

Indeed there is a problem with async put.
async_request() calls
page_put_queue.put((request, args, kwargs)) in its last line but the called method never terminates.
page_put_queue is a Queue object with mal queue length of config.max_queue_size which is 64 by default (and in this case too)
I also figured out that async_manager was never reached also in that cases the script works correctly which looks courious.
Now he have a problem inside thy python library (py 2.7.10 here) or an unhandled timeout problem. Any other suggestions?
I propose to deactivate async stuff until the problem is found.

Ah that might be the problem. async_manager was never reached because the buffer was full from previous puts to the queue and it seems the queue was not decreased. Maybe there is a timeout error when putting the page but the request wasn't removed from the queue. My problem is that that bug occurs after a long delay which might be several days. I will decrease the max_queue_size now to enforce the problem.

Change 276428 had a related patch set uploaded (by Xqt):
[bugfix] reset global stopped variable and unfreeze async put.

https://gerrit.wikimedia.org/r/276428

Hm, there is sth wrong with stopme():
I got
Waiting for 1 pages to be put. Estimated time remaining: 0:00:05
but the queue should be empty because there were no page to put!

Could you provide a new summary of the bug, explaining why it was hanging. Which part of this changeset does the 'unfreeze' part? It seems like the changeset has a few other closely related fixes in it, but they are more cosmetic, making it hard to see the exact 'freeze' bug and its fix.

Change 276428 merged by jenkins-bot:
[bugfix] Re-enable stopme() called inside a script

https://gerrit.wikimedia.org/r/276428