Hi Ross,
OK, I addressed your feedback. On a side note, coredumpctl matches based on
process names are really confusing when used with symlinks. I used a
match based on pid to avoid the confusion:
"
# coredumpctl list
TIME PID UID GID SIG COREFILE EXE
SIZE
Tue 2024-05-21 05:36:50 GMT 3442 0 0 SIGSEGV present
/usr/bin/coreutils 109.0K
# coredumpctl list coreutils
No coredumps found.
# coredumpctl list sleep
TIME PID UID GID SIG COREFILE EXE
SIZE
Tue 2024-05-21 05:36:50 GMT 3442 0 0 SIGSEGV present
/usr/bin/coreutils 109.0K
"
On Tue, Jun 11, 2024 at 12:47 PM Ross Burton <ross.bur...@arm.com> wrote:
> On 10 Jun 2024, at 17:16, Etienne Cordonnier via lists.openembedded.org
> <ecordonnier=snap....@lists.openembedded.org> wrote:
> >
> > From: Etienne Cordonnier <ecordonn...@snap.com>
> >
> > 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 systemd-coredump@.service unit is running, output may be
> incomplete.
> > ```
> >
> > Signed-off-by: Etienne Cordonnier <ecordonn...@snap.com>
> > ---
> > meta/lib/oeqa/runtime/cases/systemd.py | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/meta/lib/oeqa/runtime/cases/systemd.py
> b/meta/lib/oeqa/runtime/cases/systemd.py
> > index 80fdae240a..aed230708e 100644
> > --- a/meta/lib/oeqa/runtime/cases/systemd.py
> > +++ b/meta/lib/oeqa/runtime/cases/systemd.py
> > @@ -155,6 +155,13 @@ 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 systemd-coredump@.service to process the
> coredump
> > + for x in range(20):
> > + status, output = self.target.run('coredumpctl --quiet
> --no-pager --no-legend | wc -l')
> > + if output == "1":
> > + break
> > + time.sleep(1)
> > +
> > (status, output) = self.target.run('coredumpctl info')
>
> As someone who spent too long staring at mysterious failures in the
> debuginfod tests, I recommend you add an ‘else’ case to that loop so that
> you can explicitly fail if the timeout expires without breaking out.
>
> Also it feels like the test could be made more reliably by using matches
> instead of just asking it to list all crashes and expecting it to be one
> (what if something else crashed?), and assuming the latest crash is the one
> we’re after. If you use matches then the exit code is set to non-zero if
> the match isn’t found, so you could combine the retry loop and the actual
> test into one.
>
> Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#200523):
https://lists.openembedded.org/g/openembedded-core/message/200523
Mute This Topic: https://lists.openembedded.org/mt/106596051/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
