From: Andrea Cervesato via ltp <ltp@lists.linux.it>
To: "Cyril Hrubis" <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 1/1] kill11: Skip pipe-based core dumps per signal
Date: Fri, 10 Jul 2026 15:15:11 +0000 [thread overview]
Message-ID: <6a510c80.fc4d87c3.115da4.55fa@mx.google.com> (raw)
In-Reply-To: <alDtz7CMmysJtlAp@rei>
> Hi!
> > > Well either we do that, or we skip the signals that dump core when we
> > > are dumping into the pipe.
> >
> > To me it looks good to skip the signals which are not allowing child
> > to be killed after coredump. It's a systemd feature we can't workaround
> > in this case.
>
> Thinking of it once more, I wonder what exactly fails in the
> systemd-coredump case. I guess that it may delay the test execution a
> bit but the crashed process should eventualy quit and the test wait()
> call should collect it. If that wasn't the case systemd-coredump would
> break one of the fundamentals of UNIX process management.
Let's forget about systemd for a second.
The problem is that by using `pause()` that is not draining the buffer we
never ends the piped user-space helper. The default behaviour for a piped
helper is that kernel collect the coredump until helper drains the pipe.
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-07-10 15:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 10:28 [LTP] [PATCH v2 1/1] kill11: Skip pipe-based core dumps per signal Jan Polensky
2026-07-09 13:53 ` [LTP] " linuxtestproject.agent
2026-07-09 17:38 ` [LTP] [PATCH v2 1/1] " Andrea Cervesato via ltp
2026-07-10 12:27 ` Cyril Hrubis
2026-07-10 12:41 ` Andrea Cervesato via ltp
2026-07-10 12:45 ` Cyril Hrubis
2026-07-10 12:55 ` Andrea Cervesato via ltp
2026-07-10 13:04 ` Cyril Hrubis
2026-07-10 15:15 ` Andrea Cervesato via ltp [this message]
2026-07-14 8:43 ` Cyril Hrubis
2026-07-10 17:58 ` Jan Polensky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a510c80.fc4d87c3.115da4.55fa@mx.google.com \
--to=ltp@lists.linux.it \
--cc=andrea.cervesato@suse.com \
--cc=chrubis@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.