Consider switching to systemd-coredump for default kernel core dumps

Stéphane Graber stgraber at ubuntu.com
Tue Feb 5 21:52:48 UTC 2019


On Wed, Feb 06, 2019 at 03:05:20AM +0530, Prasanna V. Loganathar wrote:
> Hi Stephane,
> 
> Ah. I had overlooked this one. It does work well in lxc. Thanks for
> pointing that out.
> However, apport's default is to do nothing in containers.
> 
> docker run --name testbox --rm -it ubuntu bash
> > sleep 10 & kill -ABRT $(pgrep sleep)
> 
> This has no /var/crash directory. There are no dumps. Doesn't help
> with "--ulimit core=x:x" to docker option either.

You need to have apport itself installed in the container, I suspect
that the Docker containers do not have it.

Having the dump handled by apport on the host would be useless as the
host doesn't know what binary was used to produce the dump (and so can't
be used with retracers) nor can it capture any of the crash environment
information as the relevant data is in the container, not in the host.

> 
> On Tue, Feb 5, 2019 at 10:32 PM Stéphane Graber <stgraber at ubuntu.com> wrote:
> >
> > On Tue, Feb 05, 2019 at 06:36:48AM +0530, Prasanna V. Loganathar wrote:
> > > Hi Stephane,
> > >
> > > Thanks for the reply. Please correct me if I'm wrong.
> > >
> > > lxc launch ubuntu:18:04 testbox
> > > lxc exec testbox bash
> > > sleep 100 & kill -ABRT $(pgrep sleep)
> >
> > stgraber at castiana:~$ lxc launch ubuntu:18.04 testbox
> > Creating testbox
> > Starting testbox
> > stgraber at castiana:~$ lxc exec testbox bash
> > root at testbox:~# sleep 10 &
> > [1] 303
> > root at testbox:~# kill -ABRT 303
> > root at testbox:~#
> > [1]+  Aborted                 (core dumped) sleep 10
> > root at testbox:~# ls -lh /var/crash
> > total 512
> > -rw-r----- 1 root root 34K Feb  5 17:02 _bin_sleep.0.crash
> > root at testbox:~#
> >
> > > There's no crash dump anywhere.
> > >
> > > /var/crash is empty. No `core` file, etc. The default is
> > > crashes just vaporises itself - that's my biggest concern. While, for
> > > instance on a debian - you can rely on a 'core' file, or on
> > > CentOS/RHEL, you can always rely on a systemd-coredump infrastructure,
> > > and addressed so nicely by the coredumpctl command.
> > >
> > > With systemd being the init, and coredumpctl being very well
> > > architectured to manage this, I just don't see why Ubuntu shouldn't
> > > make use of that and have apport only do what it does best - which is
> > > primarily reporting.
> > >
> > >
> > >
> > > On Tue, Feb 5, 2019 at 1:57 AM Stéphane Graber <stgraber at ubuntu.com> wrote:
> > > >
> > > > On Sat, Feb 02, 2019 at 03:34:22AM +0530, Prasanna V. Loganathar wrote:
> > > > > Hi folks,
> > > > >
> > > > > Currently, `$ sysctl kernel.core_pattern` gives
> > > > > `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P`
> > > > >
> > > > > This is usually fine, however, when run from containers or lxc this
> > > > > will just error out, with no core dump being produced, due to it being
> > > > > disabled. Adding to the problem: with container or lxc, you can't just
> > > > > change it per container, and should be changed on the host. And it's
> > > > > not reasonable to expect apport in all containers either. Since, this
> > > > > is a common problem, I think it's important to consider a change in
> > > > > the default handling.
> > > > >
> > > > > There are multiple options to deal with this:
> > > > >
> > > > > 1. Drop apport as default core_pattern handler and switch to a simple
> > > > > file in either /var/crash (this requires creating /var/crash as a part
> > > > > of the installation as it's currently created by apport), or /tmp and
> > > > > let apport handle the core dump after the fact, and report it.
> > > > >
> > > > > 2. Switch to systemd-coredump, and default to it, since it already
> > > > > does this very well and provides "coredumpctl" which is much nicer to
> > > > > work with. systemd-coredump also is a part of the systemd suite of
> > > > > utils and doesn't pull in a larger dependency as apport -- which to
> > > > > date, isn't as robust (I still have "core" files being left all over
> > > > > the place due to the fact that apport reset's itself and crashes
> > > > > during startup aren't handled properly). This also has a nice
> > > > > advantage of unifying the OSS community in terms of coredump handler.
> > > > > apport can handle things from the core dumps that systemd generates,
> > > > > further on desktops.
> > > > >
> > > > > 3. Employ a tiny helper script, as the default core dump handler,
> > > > > which looks for specified programs such as "apport", "abrt",
> > > > > systemd-coredump" and pipes to them, or pipes it to /var/crash, or
> > > > > /tmp during it's absence. This does have the disadvantage of growing
> > > > > with it's own config, rather quickly.
> > > > >
> > > > > That being said, I highly suggest option 2 be used in the upcoming
> > > > > versions, and apport be a layer sitting on top of the coredumps
> > > > > generated by systemd-coredumps by either hooking into it, or by
> > > > > watching it's folders.
> > > > >
> > > > > I've also filed this as a bug here:
> > > > > https://bugs.launchpad.net/ubuntu/+bug/1813403
> > > >
> > > > Are you aware that apport is aware of containers (LXC & LXD) and will
> > > > just forward your crash to apport inside the container?
> > > >
> > > > That actually tends to be a better way to handle things that
> > > > centralizing all crashes on the host as monitoring tools running inside
> > > > the containers will operate as normal, reporting on the presence of a
> > > > crash file, as well, sending the bug report to Launchpad will then work
> > > > properly, capturing the details from the container rather than
> > > > confusingly mixing package details of the host with a crash that may
> > > > have come from a completely different release.
> > > >
> > > > There's obviously nothing wrong with someone opting out of apport and
> > > > switching to whatever core dump handler they want, but for Ubuntu,
> > > > apport has much better integration with the distribution, has hooks in
> > > > many packages and was designed with proper container support.
> > > >
> > > > --
> > > > Stéphane Graber
> > > > Ubuntu developer
> > > > http://www.ubuntu.com
> >
> > --
> > Stéphane Graber
> > Ubuntu developer
> > http://www.ubuntu.com

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20190205/9e1c4049/attachment.sig>


More information about the Ubuntu-devel-discuss mailing list