Talk:Core dump

Does the sysctl method override the whole configuration file ?

From the systemd-delta output below, it looks like the sysctl method overrides the whole configuration file instead of just adding +kernel.core_pattern=/dev/null

Probably, that makes no difference since the core dump is disabled anyway, but is this expected ?

$ systemd-delta

[OVERRIDDEN] /etc/sysctl.d/50-coredump.conf → /usr/lib/sysctl.d/50-coredump.conf

--- /usr/lib/sysctl.d/50-coredump.conf  2023-06-01 20:23:54.000000000 +0200
+++ /etc/sysctl.d/50-coredump.conf      2022-01-13 17:33:46.890167815 +0100
@@ -1,37 +1 @@
-#  This file is part of systemd.
-#
-#  systemd is free software; you can redistribute it and/or modify it
-#  under the terms of the GNU Lesser General Public License as published by
-#  the Free Software Foundation; either version 2.1 of the License, or
-#  (at your option) any later version.
-
-# See sysctl.d(5) for the description of the files in this directory.
-
-# Pipe the core file to systemd-coredump. The systemd-coredump process spawned
-# by the kernel will start a second copy of itself as the
-# systemd-coredump@.service, which will do the actual processing and storing of
-# the core dump.
-#
-# See systemd-coredump(8) and core(5).
-kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
-
-# Allow 16 coredumps to be dispatched in parallel by the kernel.
-# We collect metadata from /proc/%P/, and thus need to make sure the crashed
-# processes are not reaped until we have finished collecting what we need. The
-# kernel default for this sysctl is "0" which means the kernel doesn't wait for
-# userspace to finish processing before reaping the crashed processes. With a
-# higher setting the kernel will delay reaping until we are done, but only for
-# the specified number of crashes in parallel. The value of 16 is chosen to
-# match systemd-coredump.socket's MaxConnections= value.
-kernel.core_pipe_limit=16
-
-# Also dump processes executing a set-user-ID/set-group-ID program that is
-# owned by a user/group other than the real user/group ID of the process, or
-# a program that has file capabilities. ("2" is called "suidsafe" in core(5)).
-#
-# systemd-coredump will store the core file owned by the effective uid and gid
-# of the running process (and not the filesystem-user-ID which the kernel uses
-# when saving a core dump).
-#
-# See proc(5), setuid(2), capabilities(7).
-fs.suid_dumpable=2
+kernel.core_pattern=/dev/null

-- Cvlc (talk) 13:20, 8 June 2023 (UTC)

Why are core dump disabled anyway? The way I understand Core_dump#Disabling_automatic_core_dumps, one has to manually disable core dumps. Otherwise, they are enabled. Also, from the output you showed it is expected to override the whole configuration file. Due to kernel.core_pattern=/dev/null written to /etc/sysctl.d/50-coredump.conf, which has a higher priority then /usr/lib/sysctl.d/50-coredump.conf. See sysctl(8) § SYSTEM FILE PRECEDENCE. Regid (talk) 14:21, 17 August 2023 (UTC)

simply systemd method to disable core dumps

I suggest simplifying the systemd method to the one provided in the man page :

/etc/systemd/coredump.conf.d/custom.conf

Storage=none
ProcessSizeMax=0

Alternative: Explain the benefit of setting one and not the other.

Waiting a few days for input.

-- Cvlc (talk) 13:32, 8 June 2023 (UTC)

According to the history page, the version of the Using systemd section valid at 8 June 2023 is at Special:PermanentLink/775024#Using_systemd. Doesn't it already explains the benefits of setting one over the other? Did I misunderstood the suggested alternative? Am I missing something else?

As an aside, how could I use an internal link to the history page of the article? I mean, something along the lines of Revisions:Core dump and Talk:Core dump?

Regid (talk) 23:53, 16 August 2023 (UTC)