shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-11 20:58:27 +03:00
Code
systemd/units/systemd-coredump.socket

23 lines
643 B
SYSTEMD
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
# SPDX-License-Identifier: LGPL-2.1-or-later
Add SPDX license headers to unit files
2017-11-18 17:35:03 +01:00
#
coredump: rework coredumping logic This reworks the coredumping logic so that the coredump handler invoked from the kernel only collects runtime data about the crashed process, and then submits it for processing to a socket-activate coredump service, which extracts a stacktrace and writes the coredump to disk. This has a number of benefits: the disk IO and stack trace generation may take a substantial amount of resources, and hence should better be managed by PID 1, so that resource management applies. This patch uses RuntimeMaxSec=, Nice=, OOMScoreAdjust= and various sandboxing settings to ensure that the coredump handler doesn't take away unbounded resources from normally priorized processes. This logic is also nice since this makes sure the coredump processing and storage is delayed correctly until /var/systemd/coredump is mounted and writable. Fixes: #2286
2016-02-08 21:16:08 +01:00
# 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.
[Unit]
Description=Process Core Dump Socket
Documentation=man:systemd-coredump(8)
DefaultDependencies=no
units: let's establish the coredump socket before writting core_pattern sysctl It's a bit nicer if we only write the sysctl core_pattern once the coredump socket is established, since it's the backend for the handler. Given the systemd-coredump.socket basically has no dependencies that run before it this should not really make things slower or so, it just removes the tiny window where core pattern is in effect that wants to connect to the backend socket but cannot. The status quo isn't terrible, and not too different in effect: either way, until the socket unit is up we won't process coredumps. It's mostly what kind of behaviour you get then: an error due to /bin/false being invoked, or an error because systemd-coredump can't connect to its socket. After this patch we'll exclusively see the former.
2023-03-29 18:06:00 +02:00
Before=shutdown.target systemd-sysctl.service
systemd-coredump: Add conflict with shutdown.target Otherwise a coredump started at the inconvinient moment can stop shutdown.target leaving the system in a halfway-down state: Pulling in shutdown.target/start from systemd-poweroff.service/start Added job shutdown.target/start to transaction. ... Keeping job shutdown.target/start because of systemd-poweroff.service/start ... [ OK ] Stopped target Remote File Systems. shutdown.target: starting held back, waiting for: systemd-networkd.socket sysinit.target: stopping held back, waiting for: remount_tmp.service systemd-coredump.socket: Incoming traffic ... systemd-coredump@0-243-0.service: Trying to enqueue job systemd-coredump@0-243-0.service/start/replace Added job systemd-coredump@0-243-0.service/start to transaction. Pulling in systemd-journald.socket/start from systemd-coredump@0-243-0.service/start Added job systemd-journald.socket/start to transaction. Pulling in system.slice/start from systemd-journald.socket/start Added job system.slice/start to transaction. Pulling in -.slice/start from system.slice/start Added job -.slice/start to transaction. Pulling in system-systemd\x2dcoredump.slice/start from systemd-coredump@0-243-0.service/start Added job system-systemd\x2dcoredump.slice/start to transaction. Pulling in system.slice/start from system-systemd\x2dcoredump.slice/start Pulling in shutdown.target/stop from system-systemd\x2dcoredump.slice/start Added job shutdown.target/stop to transaction. ... Keeping job systemd-poweroff.service/stop because of umount.target/stop Keeping job shutdown.target/stop because of systemd-coredump@0-243-0.service/start
2021-04-19 01:53:45 +02:00
Conflicts=shutdown.target
coredump: rework coredumping logic This reworks the coredumping logic so that the coredump handler invoked from the kernel only collects runtime data about the crashed process, and then submits it for processing to a socket-activate coredump service, which extracts a stacktrace and writes the coredump to disk. This has a number of benefits: the disk IO and stack trace generation may take a substantial amount of resources, and hence should better be managed by PID 1, so that resource management applies. This patch uses RuntimeMaxSec=, Nice=, OOMScoreAdjust= and various sandboxing settings to ensure that the coredump handler doesn't take away unbounded resources from normally priorized processes. This logic is also nice since this makes sure the coredump processing and storage is delayed correctly until /var/systemd/coredump is mounted and writable. Fixes: #2286
2016-02-08 21:16:08 +01:00
[Socket]
ListenSequentialPacket=/run/systemd/coredump
SocketMode=0600
Accept=yes
MaxConnections=16
units: enable MaxConnectionsPerSocket= for all our Accept=yes units Let's make sure that user's cannot DoS services for other users so easily, and enable MaxConnectionsPerSocket= by default for all of them. Note that this is mostly paranoia for systemd-pcrextend.socket and systemd-sysext.socket: the socket is only accessible to root anyway, hence the accounting shouldn#t change anything. But this is just a safety net, in preparation that we open up some functionality of these services sooner or later.
2024-02-07 13:19:54 +01:00
MaxConnectionsPerSource=8
Copy Permalink