knotty: display active tasks when printing keepAlive() message

In interactive bitbake sessions it is obvious what tasks are running
when one of them hangs or otherwise takes a long time. However, in
non-interactive sessions (such as automated builds) bitbake just prints
a message saying that it is "still alive" with no clues as to what tasks
are active still.

By simply listing the active tasks when printing the keep alive message,
we don't need to parse the bitbake log to identify which of the tasks
is still active and has presumably hung.

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
 bitbake/lib/bb/ui/knotty.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Hi Ross,

Ross Burton <ross@burtonini.com> escreveu no dia segunda, 21/03/2022 à(s)
17:01:

> In interactive bitbake sessions it is obvious what tasks are running
> when one of them hangs or otherwise takes a long time. However, in
> non-interactive sessions (such as automated builds) bitbake just prints
> a message saying that it is "still alive" with no clues as to what tasks
> are active still.
>
> By simply listing the active tasks when printing the keep alive message,
> we don't need to parse the bitbake log to identify which of the tasks
> is still active and has presumably hung.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  bitbake/lib/bb/ui/knotty.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/ui/knotty.py b/bitbake/lib/bb/ui/knotty.py
> index 78888f8bdd3..50dd4229da4 100644
> --- a/bitbake/lib/bb/ui/knotty.py
> +++ b/bitbake/lib/bb/ui/knotty.py
> @@ -228,7 +228,9 @@ class TerminalFilter(object):
>
>      def keepAlive(self, t):
>          if not self.cuu:
> -            print("Bitbake still alive (%ds)" % t)
> +            print("Bitbake still alive (no events for %ds). Active
> tasks:" % t)
> +            for t in self.helper.running_tasks:
> +                print(t)
>

I think that building a new string with all tasks and call print at the end
is more efficient.

Jose

             sys.stdout.flush()
>
>      def updateFooter(self):
> --
> 2.25.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#13490):
> https://lists.openembedded.org/g/bitbake-devel/message/13490
> Mute This Topic: https://lists.openembedded.org/mt/89932958/5052612
> Group Owner: bitbake-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

I like this idea and with this implemented, it might be useful to
lower printinterval 5000s to something a bit shorter as well (or make it
configurable)

No output at all for 10+ minutes always looks strange and if I have a shell
on the builder I would check top/htop to see what's still running (if it's
something expected like chromium do_compile or something less expected like
linux-yocto do_fetch when the premirror should already be populated).
Printing this directly in knotty log file would very convenient for people
who cannot just run htop or similar on builder and tens extra lines in the
log file doesn't seem too bad.

Regards,

On Mon, Mar 21, 2022 at 6:01 PM Ross Burton <ross@burtonini.com> wrote:

> In interactive bitbake sessions it is obvious what tasks are running
> when one of them hangs or otherwise takes a long time. However, in
> non-interactive sessions (such as automated builds) bitbake just prints
> a message saying that it is "still alive" with no clues as to what tasks
> are active still.
>
> By simply listing the active tasks when printing the keep alive message,
> we don't need to parse the bitbake log to identify which of the tasks
> is still active and has presumably hung.
>
> Signed-off-by: Ross Burton <ross.burton@arm.com>
> ---
>  bitbake/lib/bb/ui/knotty.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/ui/knotty.py b/bitbake/lib/bb/ui/knotty.py
> index 78888f8bdd3..50dd4229da4 100644
> --- a/bitbake/lib/bb/ui/knotty.py
> +++ b/bitbake/lib/bb/ui/knotty.py
> @@ -228,7 +228,9 @@ class TerminalFilter(object):
>
>      def keepAlive(self, t):
>          if not self.cuu:
> -            print("Bitbake still alive (%ds)" % t)
> +            print("Bitbake still alive (no events for %ds). Active
> tasks:" % t)
> +            for t in self.helper.running_tasks:
> +                print(t)
>              sys.stdout.flush()
>
>      def updateFooter(self):
> --
> 2.25.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#13490):
> https://lists.openembedded.org/g/bitbake-devel/message/13490
> Mute This Topic: https://lists.openembedded.org/mt/89932958/3617156
> Group Owner: bitbake-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [
> Martin.Jansa@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

On Mon, 21 Mar 2022 at 17:05, Jose Quaresma <quaresma.jose@gmail.com> wrote:
> I think that building a new string with all tasks and call print at the end is more efficient.

This only happens if bitbake has been idle for quite some time (5000
seconds) so efficiency isn't key, and I'm not convinced that
constructing a long string and then calling print() once will be
measurable faster than not doing lots of string manipulation.

Ross

On Mon, 21 Mar 2022 at 17:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> I like this idea and with this implemented, it might be useful to lower printinterval 5000s to something a bit shorter as well (or make it configurable)
>
> No output at all for 10+ minutes always looks strange and if I have a shell on the builder I would check top/htop to see what's still running (if it's something expected like chromium do_compile or something less expected like linux-yocto do_fetch when the premirror should already be populated). Printing this directly in knotty log file would very convenient for people who cannot just run htop or similar on builder and tens extra lines in the log file doesn't seem too bad.

I actually agree.  How about five or ten minutes?  This only happens
for non-interactive builds so most interactive users won't even
notice.

Ross