15881 2025-05-28 07:39:14 +0000 consecutive bitbake-getvar invocations cause log messages to be sent to stdout 2026-10-01 15:47:29 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 5.2 x86 Multiple NEW Medium+ normal 6.2 M2 1 ejo richard.purdie ccasciato poky.bs.watcher poky.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 102086 0 ejo 2025-05-28 07:39:14 +0000 When using bitbake-getvar for scripting, I have two consecutive calls to get two different variable contents. The output should be stored in a variable, thus, the commands should only emit the value of the queried variable: YOCTO_BUILD=$(bitbake-getvar -r busybox --value B -q) YOCTO_SOURCE=$(bitbake-getvar -r busybox --value S -q) While the first call only prints the variable value to stdout, the second call prints: NOTE: Reconnecting to bitbake server... NOTE: Retrying server connection (#1)... (09:07:49.112555) /path/to/tmp/work/../build which will break the script's variable. I've noted this only happens when the bitbake from the previous call is still terminating (seems to work fine for still running/memres bitbake). Digging through the code, I realized this is a somewhat intentional behavior for bitbake that ensures no log messages get lost. It happens in the print_ui_queue() method, registered as an exit handler, which drains all remaining UI LogEvents (if no UI is present) and dumps them using simple stdout/stderr log handlers. My understanding is that the terminating bitbake still receives and prints these logs before finally exiting. What's unclear to me is if this can be avoided for the bitbake-getvar use case. An option I have thought about is to ensure the previous bitbake is fully shut down before spawning a new one. But maybe there are also options for silencing the log draining? Or something conceptual I haven't thought of?