shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-28 11:21:59 +03:00
Code
46e98dfcc7
systemd/tmpfiles.d/systemd-pstore.conf

35 lines
1.5 KiB
Plaintext
Raw Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 07:23:58 +03:00
# SPDX-License-Identifier: LGPL-2.1-or-later
pstore: introduce tmpfiles.d/systemd-pstore.conf The systemd pstore service archives the contents of /sys/fs/pstore upon boot so that there is room for a subsequent dump. The issue is that while the service is present, the kernel still needs to be configured to write data into the pstore. The kernel has two parameters, crash_kexec_post_notifiers and printk.always_kmsg_dump, that control writes into pstore. The crash_kexec_post_notifiers parameter enables the kernel to write dmesg (including stack trace) into pstore upon a panic, and printk.always_kmsg_dump parameter enables the kernel to write dmesg upon a shutdown (shutdown, reboot, halt). As it stands today, these parameters are not managed/manipulated by the systemd pstore service, and are solely reliant upon the user [to have the foresight] to set them on the kernel command line at boot, or post boot via sysfs. Furthermore, the user would need to set these parameters in a persistent fashion so that that they are enabled on subsequent reboots. This patch introduces the setting of these two kernel parameters via the systemd tmpfiles technique.
2020-04-14 00:22:04 +03:00
#
# The systemd-pstore.service(1) archives the contents of /sys/fs/pstore
# upon boot so that there is room for a subsequent dump. This service
# is enabled with:
# systemctl enable systemd-pstore
#
# With the service enabled, the kernel still needs to be configured
# to write data into the pstore. The kernel has two parameters,
# crash_kexec_post_notifiers and printk.always_kmsg_dump, that
# control writes into pstore.
#
# The crash_kexec_post_notifiers parameter enables the kernel to write
pstore: don't enable crash_kexec_post_notifiers by default commit f00c36641a253f4ea659ec3def5d87ba1336eb3b enabled crash_kexec_post_notifiers by default regardless of whether pstore is enabled or not. The original intention to enabled this option by default is that it only affects kernel post-panic behavior, so should have no harm. But this is not true if the user wants a reliable kdump. crash_kexec_post_notifiers is known to cause problem with kdump, and it's documented in kernel. It's not easy to fix the problem because of how kdump works. Kdump expects the crashed kernel to jump to an pre-loaded crash kernel, so doing any extra job before the jump will increase the risk. It depends on the user to choose between having a reliable kdump or some other post-panic debug mechanic. So it's better to keep this config untouched by default, or it may put kdump at higher risk of failing silently. User should enable it by uncommenting the config line manually if pstore is always needed. Also add a inline comment inform user about the potential issue. Thanks to Dave Young for finding out this issue. Fixes #16661 Signed-off-by: Kairui Song <kasong@redhat.com>
2020-08-04 12:30:51 +03:00
# dmesg (including stack trace) into pstore upon a panic even if kdump
# is loaded, only needed if you want to use pstore with kdump. Without
# this parameter, kdump could block writing to pstore for stability
# reason. Note this increases the risk of kdump failure even if pstore
# is not available.
#
# The printk.always_kmsg_dump parameter enables the kernel to write dmesg
pstore: introduce tmpfiles.d/systemd-pstore.conf The systemd pstore service archives the contents of /sys/fs/pstore upon boot so that there is room for a subsequent dump. The issue is that while the service is present, the kernel still needs to be configured to write data into the pstore. The kernel has two parameters, crash_kexec_post_notifiers and printk.always_kmsg_dump, that control writes into pstore. The crash_kexec_post_notifiers parameter enables the kernel to write dmesg (including stack trace) into pstore upon a panic, and printk.always_kmsg_dump parameter enables the kernel to write dmesg upon a shutdown (shutdown, reboot, halt). As it stands today, these parameters are not managed/manipulated by the systemd pstore service, and are solely reliant upon the user [to have the foresight] to set them on the kernel command line at boot, or post boot via sysfs. Furthermore, the user would need to set these parameters in a persistent fashion so that that they are enabled on subsequent reboots. This patch introduces the setting of these two kernel parameters via the systemd tmpfiles technique.
2020-04-14 00:22:04 +03:00
# upon a normal shutdown (shutdown, reboot, halt).
#
# To configure the kernel parameters, uncomment the appropriate
tree-wide: replace "plural(s)" by "plurals" (s) is just ugly with a vibe of DOS. In most cases just using the normal plural form is more natural and gramatically correct. There are some log_debug() statements left, and texts in foreign licenses or headers. Those are not touched on purpose.
2022-10-15 17:06:20 +03:00
# lines below. The value written is either 'Y' to enable the
pstore: introduce tmpfiles.d/systemd-pstore.conf The systemd pstore service archives the contents of /sys/fs/pstore upon boot so that there is room for a subsequent dump. The issue is that while the service is present, the kernel still needs to be configured to write data into the pstore. The kernel has two parameters, crash_kexec_post_notifiers and printk.always_kmsg_dump, that control writes into pstore. The crash_kexec_post_notifiers parameter enables the kernel to write dmesg (including stack trace) into pstore upon a panic, and printk.always_kmsg_dump parameter enables the kernel to write dmesg upon a shutdown (shutdown, reboot, halt). As it stands today, these parameters are not managed/manipulated by the systemd pstore service, and are solely reliant upon the user [to have the foresight] to set them on the kernel command line at boot, or post boot via sysfs. Furthermore, the user would need to set these parameters in a persistent fashion so that that they are enabled on subsequent reboots. This patch introduces the setting of these two kernel parameters via the systemd tmpfiles technique.
2020-04-14 00:22:04 +03:00
# kernel parameter, or 'N' to disable the kernel parameter.
#
# After making a change to this file, do:
# systemd-tmpfiles --create path/to/tmpfiles.d/systemd-pstore.conf
#
# These changes are automatically applied on future re-boots.
d /var/lib/systemd/pstore 0755 root root 14d
tmpfiles: don't complain if we can't enable pstore in containers
2020-05-25 17:11:51 +03:00
#w- /sys/module/printk/parameters/always_kmsg_dump - - - - Y
pstore: don't enable crash_kexec_post_notifiers by default commit f00c36641a253f4ea659ec3def5d87ba1336eb3b enabled crash_kexec_post_notifiers by default regardless of whether pstore is enabled or not. The original intention to enabled this option by default is that it only affects kernel post-panic behavior, so should have no harm. But this is not true if the user wants a reliable kdump. crash_kexec_post_notifiers is known to cause problem with kdump, and it's documented in kernel. It's not easy to fix the problem because of how kdump works. Kdump expects the crashed kernel to jump to an pre-loaded crash kernel, so doing any extra job before the jump will increase the risk. It depends on the user to choose between having a reliable kdump or some other post-panic debug mechanic. So it's better to keep this config untouched by default, or it may put kdump at higher risk of failing silently. User should enable it by uncommenting the config line manually if pstore is always needed. Also add a inline comment inform user about the potential issue. Thanks to Dave Young for finding out this issue. Fixes #16661 Signed-off-by: Kairui Song <kasong@redhat.com>
2020-08-04 12:30:51 +03:00
#w- /sys/module/kernel/parameters/crash_kexec_post_notifiers - - - - Y
Copy Permalink