| Message ID | 20260827123925.633743-1-rouven.rastetter.ext@karlstorz.com |
|---|---|
| State | New |
| Headers | show |
| Series | knotty: Hide 'Bitbake still alive' message with quiet>2 | expand |
On Thu, 2026-08-27 at 14:39 +0200, Rouven Rastetter via lists.openembedded.org wrote: > It can happen that bitbake-getvar takes a very long time, probably due > to NFS locking. But even with the `--quiet` flag (which equals > `self.quiet=3` in `TerminalFilter`) the 'Bitbake still alive' message is > still printed, causing errors when using the output of `bitbake-getvar` > in scripts. > > This change silences the 'Bitbake still alive' message for `self.quiet>2`. > --- > lib/bb/ui/knotty.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) The "still alive" messages only happen after 10 minutes. Under what circumstances does bitbake-getvar take 10 minutes? This message is really designed more as debug - to give an idea of where the system is hanging, or an idea of things being alive in very long running builds. bitbake-getvar shouldn't be hanging on NFS locking? I'm just surprised/concerned this patch is even necessary... Cheers, Richard
Hi Richard, we are still investigating why it hangs that long on our CI machines sometimes. I agree that it is strange. The reason why I contributed this is because I think a --quiet flag of a command line tool should be respected no matter what. Maybe it should be changed in bitbake-getvar instead, but that would be a bigger change i think. If you disagree with that it's also fine, I just thought it doesn't hurt to ask
diff --git a/lib/bb/ui/knotty.py b/lib/bb/ui/knotty.py index 15025e8dd..185c7f307 100644 --- a/lib/bb/ui/knotty.py +++ b/lib/bb/ui/knotty.py @@ -262,7 +262,7 @@ class TerminalFilter(object): return "%ds" % (sec) def keepAlive(self, t): - if not self.cuu: + if not self.cuu and self.quiet <= 2: msgbuf = ["Bitbake still alive (no events for %ds). Active tasks:" % t] for t in self.helper.running_tasks: msgbuf.append(str(t))