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

[jseba]

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

• SIGABRT
• SIGBUS
• SIGFPE
• SIGILL
• SIGIOT (alias for SIGABRT)
• SIGQUIT
• SIGSEGV
• SIGSYS
• SIGTRAP
• SIGXCPU

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]

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.