Systemd/man/systemd-pstore.service.xml

118 lines
5.1 KiB
XML
Raw Normal View History

pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
<refentry id="systemd-pstore" conditional='ENABLE_PSTORE'
xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>systemd-pstore.service</title>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>systemd-pstore.service</refentrytitle>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>systemd-pstore.service</refname>
<refname>systemd-pstore</refname>
<refpurpose>A service to archive contents of pstore</refpurpose>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
</refnamediv>
<refsynopsisdiv>
<para><filename>/usr/lib/systemd/systemd-pstore</filename></para>
<para><filename>systemd-pstore.service</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><filename>systemd-pstore.service</filename> is a system service that archives the
contents of the Linux persistent storage filesystem, pstore, to other storage,
thus preserving the existing information contained in the pstore, and clearing
pstore storage for future error events.</para>
<para>Linux provides a persistent storage file system, pstore, that can store
error records when the kernel dies (or reboots or powers-off). These records in
turn can be referenced to debug kernel problems (currently the kernel stuffs
the tail of the dmesg, which also contains a stack backtrace, into pstore).</para>
<para>The pstore file system supports a variety of backends that map onto persistent
storage, such as the ACPI ERST and UEFI variables. The pstore backends
typically offer a relatively small amount of persistent storage, e.g. 64KiB,
which can quickly fill up and thus prevent subsequent kernel crashes from
recording errors. Thus there is a need to monitor and extract the pstore
contents so that future kernel problems can also record information in the
pstore.</para>
<para>The pstore service is independent of the kdump service. In cloud environments
specifically, host and guest filesystems are on remote filesystems (eg. iSCSI
or NFS), thus kdump relies (implicitly and/or explicitly) upon proper operation
of networking software *and* hardware *and* infrastructure. Thus it may not be
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
possible to capture a kernel coredump to a file since writes over the network
may not be possible.</para>
<para>The pstore backend, on the other hand, is completely local and provides a path
to store error records which will survive a reboot and aid in post-mortem
debugging.</para>
<para>The <command>systemd-pstore</command> executable does the actual work. Upon starting,
the <filename>pstore.conf</filename> file is read and the <filename>/sys/fs/pstore</filename>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
directory contents are processed according to the options. Pstore files are written to the
journal, and optionally saved into <filename>/var/lib/systemd/pstore</filename>.</para>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
</refsect1>
<refsect1>
<title>Configuration</title>
<para>The behavior of <command>systemd-pstore</command> is configured through the configuration file
<filename>/etc/systemd/pstore.conf</filename> and corresponding snippets
<filename>/etc/systemd/pstore.conf.d/*.conf</filename>, see
<citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
<refsect2>
<title>Disabling pstore processing</title>
<para>To disable pstore processing by <command>systemd-pstore</command>,
set <programlisting>Storage=none</programlisting> in
<citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para>
</refsect2>
<refsect2>
<title>Controlling kernel parameters</title>
<para> The kernel has two parameters,
<filename>/sys/module/kernel/parameters/crash_kexec_post_notifiers</filename> and
<filename>/sys/module/printk/parameters/always_kmsg_dump</filename>,
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 or crash, and
printk.always_kmsg_dump parameter enables the kernel to write dmesg
upon a normal shutdown (shutdown, reboot, halt). These kernel
parameters are managed via the
<citerefentry><refentrytitle>tmpfiles.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
mechanism, specifically the file <filename>/usr/lib/tmpfiles/systemd-pstore.conf</filename>.
</para>
</refsect2>
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
</refsect1>
<refsect1>
<title>Usage</title>
<para>Data stored in the journal can be viewed with
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
as usual.</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>pstore.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>