coredump: support new kernel coredump interface by yuwata · Pull Request #39287 · systemd/systemd

yuwata · 2025-10-13T01:41:02Z

Since kernel v6.17, core pattern can take a path to unix socket. This adds support for the interface.
See also: https://lore.kernel.org/all/20250603-work-coredump-socket-protocol-v2-0-05a5f0c18ecc@kernel.org/

poettering · 2025-10-14T10:16:49Z

may i suggest splitting this into three prs? one with the refactorings, one with the new helpers, and then finally the actually new code that hooks things up with the new kernel interface?

i think the first two we can merge very quickly.

poettering · 2025-10-14T10:19:31Z

+                return log_error_errno(r, "Failed to add COREDUMP_TIMESTAMP= field: %m");
+
+        struct rlimit rl;
+        r = pid_getrlimit(info.pid, RLIMIT_CORE, &rl);


time for pidref_getrlimit()?

It is not necessary at least here, as we will call pidref_verify() later. So, I'd like to keep this as is at lest now.

poettering · 2026-02-05T10:36:26Z

+        assert(socket);
+        assert(socket->state == SOCKET_WAITING_MARKER);
+        assert(fd >= 0);
+


we never check revents in this functions, why not?

at the very last we should encode our assumptions here via an assert(), about which flags in it will be set or not.

Not sure, but assert does not work. I will take a look later.

yuwata · 2026-02-06T06:07:24Z

@poettering @YHNdnzj Thank you for the review. All comments/requests are addressed. Upgrading the green label.

YHNdnzj · 2026-02-06T17:16:21Z

hmm, maybe place a concurrency limit on the parent slice, similar to what we do for mute-console, so we don't spawn multiple servers that race with each other

YHNdnzj · 2026-02-06T17:20:11Z

+FileDescriptorName=varlink
+SocketMode=0600
+Accept=yes
+MaxConnections=16


and maybe limit this to 8 or so, because there really shouldn't be more than 1 client irl

YHNdnzj · 2026-02-06T17:25:07Z

+Description=Listen Kernel Core Dump Socket
+Documentation=man:systemd-coredump(8)
+DefaultDependencies=no
+After=systemd-coredump-register.socket systemd-journald.socket systemd-sysctl.service


hmm, IIUC this relies on the fact that we're started later than sysctl.service to register the new pattern? does that really work though? people tend to invoke sysctl --system to reload all sysctls after modifying config, which would also override whatever we set here?

So, hmm, I figure we'll need a "boot only" type of sysctl config a la tmpfiles --boot and guard our core pattern config behind that?

Maybe, we should introduce drop-in sysctl config to avoid the override by later invocation.

YHNdnzj · 2026-02-06T17:25:52Z


+int pidfd_info_mask_is_supported(uint64_t mask) {
+        static thread_local uint64_t cached_mask = 0;
+        static thread_local int cached = 0; /* 0 when not cached, 1 when cached, negative errno on failure. */


why thread_local?

Now it is not necessary, but src/basic may be called through libsystemd, which may be multi-threaded.

YHNdnzj · 2026-02-06T17:29:43Z

btw, I'm wondering: maybe this can be generalized to be a varlink interface for systemd-sysctl? There's nothing special about core_pattern anyways here?

Sounds nice.

if that's desirable then yeah we should do #39287 (comment), following the idea of ".control" unit file drop-in dir.

YHNdnzj · 2026-02-06T19:08:45Z

I think the sysctl part needs more thinking, hence tentatively dropping the label.

Since glibc-2.43, sys/pidfd.h defines struct pidfd_info, but its definition is slightly older compared with linux v6.19. See https://sourceware.org/git/?p=glibc.git;a=commit;h=c0c9524a11c56889ec5b1de2e0b78112f2ebc0b7 https://lore.kernel.org/all/[email protected]/ This imports linux/pidfd.h (and linux/ioctl.h) from the kernel, and make our header that overrides sys/pidfd.h includes linux/pidfd.h. Then, we can always use uptodate definition of struct pidfd_info. Note, linux/pidfd.h includes linux/fcntl.h, but it conflicts glibc's fcntl.h. So, this also replaces linux/fcntl.h with glibc's fcntl.h.

Since kernel v6.19, we can get supported flags by ioctl(PIDFD_GET_INFO) by using PIDFD_INFO_SUPPORTED_MASK.

This is useful when writing coredump pattern. But the logic itself is quite generic. Let's add the helper in our basic library. Preparation for later change.

This adds new mode to invoke systemd-coredump executable. When invoked with '--register' option, it accepts a varlink method to set new core pattern to /proc/sys/kernel/core_pattern. This is necessary as the core pattern cannot be registered from sandboxed environment, but we'd like to run the main service, which will be added in later commit, in a sandbox.

…socket protocol The function process socket connection between the kernel and process the protocol to receive coredump through the socket, which is supported since the kernel v6.17. See also: https://lore.kernel.org/all/20250603-work-coredump-socket-protocol-v2-0-05a5f0c18ecc@kernel.org/ This is currently not used. Preparation for later change.

…tion about crashed process through socket peer On coredump socket mode, information about the crashed process needs to be obtained from pidfd, which can be obtained by the socket peer. This is currently not used. Preparation for later commit.

When invoked with '--container' option, which is run in a container, systemd-coredump accepts varlink connection to transfer coredump from the host to the container. The new container interface is currently not used. Preparation for later commit.

Since kernel v6.17, we can set a path to unix socket to core_pattern (with request mode). See also: https://lore.kernel.org/all/20250603-work-coredump-socket-protocol-v2-0-05a5f0c18ecc@kernel.org/ When systemd-coredump is invoked with '--manager' option, it creates a unix socket to receive coredumps from the kernel, requests varlink helper to register the socket to core pattern, and wait for coredumps. When a coredump is received, it forwards the coredump to the corresponding container if the crashed process is running in a container, otherwise saves the coredump to the local storage.

…P_SIGNAL are since v6.19

yuwata · 2026-02-13T07:33:36Z

(No comments are addressed yet. Just for checking CIs.)

github-actions Bot added documentation build-system util-lib tests coredump hostname units meson labels Oct 13, 2025

yuwata force-pushed the coredump branch 3 times, most recently from 3a45a88 to 786d702 Compare October 13, 2025 05:59