shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00
Code
bff8f2543b
systemd-stable/units/systemd-coredump@.service.in

38 lines
1.1 KiB
SYSTEMD
Raw Normal View History

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 23:16:08 +03: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
Documentation=man:systemd-coredump(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-remount-fs.service systemd-journald.socket
Requires=systemd-journald.socket
Before=shutdown.target
[Service]
ExecStart=-@rootlibexecdir@/systemd-coredump
Nice=9
OOMScoreAdjust=500
units: lock down coredump service a bit Dissecting a coredump is possibly risky and might take a while, hence lock down the unit as much as we can.
2017-02-09 13:17:45 +03:00
RuntimeMaxSec=5min
PrivateTmp=yes
PrivateDevices=yes
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 23:16:08 +03:00
PrivateNetwork=yes
units: switch on ProtectSystem=strict for our long running services Let's step up the protection a notch
2017-02-09 12:58:28 +03:00
ProtectSystem=strict
units: lock down coredump service a bit Dissecting a coredump is possibly risky and might take a while, hence lock down the unit as much as we can.
2017-02-09 13:17:45 +03:00
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictNamespaces=yes
RestrictAddressFamilies=AF_UNIX
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io @reboot @swap
units: set SystemCallArchitectures=native on all our long-running services
2017-02-09 00:32:37 +03:00
SystemCallArchitectures=native
units: set LockPersonality= for all our long-running services (#6819) Let's lock things down. Also, using it is the only way how to properly test this to the fullest extent.
2017-09-14 20:45:40 +03:00
LockPersonality=yes
units: use {State,Logs}Directory= if they are applicable
2017-08-02 11:35:11 +03:00
StateDirectory=systemd/coredump
Copy Permalink