Also, one can ask simply ask the corollary - why not just leave the dump
files as it is, like how RedHat does? To some, like myself it's invaluable
in some situations, to some others - indifference, and to some other who
don't like it (I can't really think of a reason why other than it taking up
sp
Smaller companies probably have some one in the team with access, in most
scenarios. Others, when all hope is lost, you can still get your dump, by
reaching out to your admins. Which is the point of the core dump anyway in
most production circumstances - to be able to provide the final frontier of
On Wed, 2019-02-06 at 05:57 +0530, Prasanna V. Loganathar wrote:
> Now, having said that, systemd-coredump in the Red Hat land just
> leave the dumps on the host.
I wonder how that would be useful when the people who are responsible
for the applications running inside the container have no (root)
>
> Nope, everything landing through the helper on the host is what happens
> whenever you have a core pattern that starts with a "|". Similarly, any
> pattern which isn't just a file name (like "core") but is instead an
> absolute path, will be treated as an absolute path on the host, not in
> the
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)
There's no crash dump anywhere.
/var/crash is empty. No `core` file, etc. The default is
crashes just vaporises itself - that's my bigge
On Wed, Feb 06, 2019 at 04:57:32AM +0530, Prasanna V. Loganathar wrote:
> >
> > So having all the dumps centralized on the host when you don't know what
> > container it came from and may no longer have any of the environment
> > information is completely useless.
> >
>
> Adding on to my previous
>
> So having all the dumps centralized on the host when you don't know what
> container it came from and may no longer have any of the environment
> information is completely useless.
>
Adding on to my previous reply, perhaps there's a misunderstanding on this
one? Who's forwarding dumps to the h
>
> Except for the part where a coredump for an unknown binary is useless.
If I have a service that crashes in a container. I'd like to get back into
the container and inspect why. Simply throwing out unknown binary crashes
doesn't exactly seem like a stellar decision to me. And unknown binary to
On Wed, Feb 06, 2019 at 03:35:23AM +0530, Prasanna V. Loganathar wrote:
> >
> > You need to have apport itself installed in the container, I suspect
> > that the Docker containers do not have it.
>
>
> This will make no difference. Doing an `apt update && apt install -y
> apport` will not do any
>
> You need to have apport itself installed in the container, I suspect
> that the Docker containers do not have it.
This will make no difference. Doing an `apt update && apt install -y
apport` will not do any good, as apport is set to disable itself on
containers.
> Having the dump handled by
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
> > sl
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
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@castiana:~$ lxc launch ubuntu:18.04 testbo
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,
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: wi
15 matches
Mail list logo
