(#2211416) Follow-up fixes for pstore #394
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Tracker - 2211416 The following commits meet all requirements
|
systemd-rhel-bot
changed the title
dtardon
changed the title
systemd-rhel-bot
changed the title
|
@dtardon Please rebase this one. Thank you. |
systemd-pstore does not use any symbol from libdw, and never did, but the dependency was listed since the beginning (cherry picked from commit 5361f62) Related: #2211416
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. (cherry picked from commit f00c366) Resolves: #2211416
(cherry picked from commit 203c07c) Related: #2211416
commit f00c366 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> (cherry picked from commit edb8c98) Related: #2211416
dtardon
force-pushed
the
bz2158832-pstore-followup
branch
from
d06ceef to
7572e73
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: #2211416
Follow-up-for: #353