Hi Richard,
I sent a second version of the patch which shouldn't be racy. I have
implemented it slightly differently from your suggestion because I think it
is also a bit racy (if we start checking whether [email protected]
is running in one thread only after it has already finished processing the
coredump in the other thread, then we'll be stuck in a retry loop until the
overall timeout).

Étienne

On Mon, Jun 10, 2024 at 2:53 PM Richard Purdie <
[email protected]> wrote:

> On Mon, 2024-06-10 at 14:39 +0200, Etienne Cordonnier via
> lists.openembedded.org wrote:
> > From: Etienne Cordonnier <[email protected]>
> >
> > Fix this error where 'coredumpctl info' warns that the coredump is still
> being
> > processed:
> >
> > ```
> > AssertionError: 1 != 0 : MiniDebugInfo Test failed: No match found.
> > -- Notice: 1 [email protected] unit is running, output may be
> incomplete.
> > ```
> >
> > Signed-off-by: Etienne Cordonnier <[email protected]>
> > ---
> >  meta/lib/oeqa/runtime/cases/systemd.py | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/lib/oeqa/runtime/cases/systemd.py
> b/meta/lib/oeqa/runtime/cases/systemd.py
> > index 80fdae240a..17fa660ace 100644
> > --- a/meta/lib/oeqa/runtime/cases/systemd.py
> > +++ b/meta/lib/oeqa/runtime/cases/systemd.py
> > @@ -155,6 +155,9 @@ class SystemdServiceTests(SystemdTest):
> >          self.target.run('kill -SEGV %s' % output)
> >          self.assertEqual(status, 0, msg = 'Not able to find process
> that runs sleep, output : %s' % output)
> >
> > +        # Give some time to [email protected] to process the
> coredump
> > +        time.sleep(1)
> > +
> >          (status, output) = self.target.run('coredumpctl info')
> >          self.assertEqual(status, 0, msg='MiniDebugInfo Test failed: %s'
> % output)
> >          self.assertEqual('sleep_for_duration (busybox.nosuid' in output
> or 'xnanosleep (sleep.coreutils' in output,
> >
>
> Specific sleep values like this are a red flag, it all depends on how
> much load systems are under and we've had a lot of problems with these
> kinds of things.
>
> Instead, you should probably detect "[email protected] unit is
> running" in the command output and retry if that is the case with an
> overall timeout/error in case it never completes.
>
> Cheers,
>
> Richard
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200480): 
https://lists.openembedded.org/g/openembedded-core/message/200480
Mute This Topic: https://lists.openembedded.org/mt/106591401/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to