10061 2016-08-02 02:04:29 +0000 Ctrl+C during BB_HASHCHECK_FUNCTION execution does not interrupt processing nicely 2026-04-23 15:22:25 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 2.0 x86 Multiple NEW Medium+ minor 6.99 1 bluelightning unassigned Aryaman.Gupta JPEWhacker poky.bs.watcher poky.watcher randy.macleod richard.purdie sgw tgamblin --- --- No (bug/feature does not impact docs) oldest_to_newest 64773 0 bluelightning 2016-08-02 02:04:29 +0000 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. 64871 1 richard.purdie 2016-08-04 14:51:54 +0000 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. 94914 2 randy.macleod 2023-02-09 15:57:30 +0000 Some progress made but likely still a problem. 96104 3 randy.macleod 2023-07-26 21:22:06 +0000 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. 96431 4 tgamblin 2023-09-14 15:43:19 +0000 Moved to M4. 97084 5 randy.macleod 2023-10-30 15:29:14 +0000 Bulk move to 5.0 M1. -- Randy 97656 6 randy.macleod 2023-12-21 23:28:25 +0000 Bulk move of 52 5.0-M1 bugs to M2. 97994 7 randy.macleod 2024-01-25 14:28:46 +0000 Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3. 98301 8 randy.macleod 2024-02-22 19:53:23 +0000 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.