If I hit Ctrl+C during the "Checking sstate mirror object availability" stage in OE (which is when BB_HASHCHECK_FUNCTION is being called, i.e. setscene_depvalid() in sstate.bbclass) then I see the following: ------------ snip ------------ Keyboard Interrupt, closing down... WARNING: Timeout while attempting to communicate with bitbake server WARNING: Timeout while attempting to communicate with bitbake server WARNING: Timeout while attempting to communicate with bitbake server WARNING: Timeout while attempting to communicate with bitbake server ERROR: Gave up; Too many tries: timeout while attempting to communicate with bitbake server NOTE: Executing SetScene Tasks NOTE: Sending SIGTERM to remaining 1 tasks NOTE: Tasks Summary: Attempted 109 tasks of which 109 didn't need to be rerun and all succeeded. NOTE: Writing buildhistory WARNING: /home/paul/poky/poky/bitbake/lib/bb/event.py:124: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/paul/poky/poky/build/tmp/log/cooker/genericx86-64/20160802015804.log' mode='a' encoding='UTF-8'> logger.handlers = [console] ------------ snip ------------ This can take quite a bit of time - I'm guessing it doesn't quit until setscene_depvalid() actually returns.
I can see what happens here, the server is running subprocess calls. The Ctrl+C is processed by the UI and queues a "stop" command for the server which it only processes when it returns from the function. If you propagate the Ctrl+C to the server, things get very messy as you never get clean exit paths and the shutdown isn't graceful. I'm not sure what we can do to easily make for a better user experience here without reintroducing all the bugs which caused us to define a shutdown process in the first place.
Some progress made but likely still a problem.
Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team.
Moved to M4.
Bulk move to 5.0 M1. -- Randy
Bulk move of 52 5.0-M1 bugs to M2.
Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.
Bulk move of bugs from 5.0-M3 to 5.99. The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024. If you disagree, please move back to a 5.[012...]-M* milestone.