search

google / gvisor

Application Kernel for Containers
https://gvisor.dev
Apache License 2.0
15.9k stars 1.31k forks source link

Option to ignore coredump exit codes from the sandboxed container init process #11000

Open jseba opened 1 month ago

jseba commented 1 month ago

Description

We've been getting spurious coredumps from our sandboxed containers that have had no panic trace from gVisor itself. After digging into a bunch of them, I've noticed that the applications inside the container are panicking or otherwise exiting with SIGSEGV/SIGABRT signals, which the sandbox is returning as it's own exit code. This causes systemd-coredump (or whatever /proc/sys/kernel/core_pattern is configured to do) to try and process a coredump event with no data, because there was no coredump generated by the sandbox process on the host.

Is there any point to gVisor exiting with signals that indicate a coredump? From man 7 signals, this set includes

If there's no core to be generated, this just causes noise since I don't believe systemd-coredumpd can be configured to ignore empty coredumps currently.

Is this feature related to a specific bug?

No response

Do you have a specific solution in mind?

No response

kevinGC commented 1 month ago

Is there any point to gVisor exiting with signals that indicate a coredump?

I think we just haven't run into this before. gVisor returns the init process status because it's generally useful to callers.

An option to mask out the signal from the exit code could work.