SYSTEMD-PSTORE.SERVICE(8)
๐พ SYSTEMD-PSTORE.SERVICE(8) โ aka systemd-pstore.service, aka the little service that rescues your kernel's last words โจ
okay bestie, pull up a chair because this page is about systemd-pstore.service and its buddy the systemd-pstore binary โ a service whose whole job is archiving the contents of the Linux persistent storage filesystem, pstore, into other storage. That way the existing info in pstore is preserved, and pstore gets cleared out so future error events have somewhere to land. iconic behavior honestly ๐
๐ธ NAME ๐ธ
systemd-pstore.service, systemd-pstore โ a service to archive contents of pstore ๐ซถ
โจ SYNOPSIS โจ
/usr/lib/systemd/systemd-pstore
systemd-pstore.service
๐ DESCRIPTION ๐
so, systemd-pstore.service is a system service that archives the contents of the Linux persistent storage filesystem, pstore, to other storage. Why? Two reasons, bestie: it preserves the existing information contained in the pstore, and it clears pstore storage for future error events. it's giving housekeeping but make it forensic ๐ฅ
Linux provides a persistent storage file system, pstore, that can store error records when the kernel dies (or reboots or powers-off). Those records can in turn be referenced to debug kernel problems โ and rn the kernel stores the tail of the kernel log, which also contains a stack backtrace, into pstore. so yeah, it's basically the kernel's diary for when things go extremely wrong ๐ญ
The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST and UEFI variables. And here's the thing โ those pstore backends typically offer a relatively small amount of persistent storage, like e.g. 64KiB. That is tiny, and it can quickly fill up, which then prevents subsequent kernel crashes from recording errors at all. so there's a real need to monitor and extract the pstore contents, so that future kernel problems can also record information in the pstore. no cap. ๐
the pstore service is independent of the kdump service, and this part matters a lot ๐
In cloud environments specifically, host and guest filesystems are on remote filesystems (e.g. iSCSI or NFS), which means kdump relies โ implicitly and/or explicitly โ upon proper operation of networking software and hardware and infrastructure. So it may not be possible to capture a kernel coredump to a file, since writes over the network may not be possible. literally three layers of "and" bestie, that's a lot of ways for things to go sideways ๐
The pstore backend, on the other hand, is completely local, and it provides a path to store error records which will survive a reboot and aid in post-mortem debugging. local queen behavior ๐
The systemd-pstore executable does the actual work. Upon starting, the pstore.conf file is read, and the /sys/fs/pstore/ directory contents are processed according to the options. Pstore files are written to the journal, and optionally saved into /var/lib/systemd/pstore/. ๐
๐ฆ CONFIGURATION ๐ฆ
The behavior of systemd-pstore is configured through the configuration file /etc/systemd/pstore.conf and corresponding snippets /etc/systemd/pstore.conf.d/*.conf, see pstore.conf(5). โจ
๐ค Disabling pstore processing
To disable pstore processing by systemd-pstore, set
Storage=none
in pstore.conf(5). that's it, that's the whole vibe. one line and she's off duty ๐
๐ง Kernel parameters
The kernel has two parameters, /sys/module/kernel/parameters/crash_kexec_post_notifiers and /sys/module/printk/parameters/always_kmsg_dump, that control writes into pstore. Let's break it down:
- The first one enables storing of the kernel log (including stack trace) into pstore upon a panic or crash. ๐
- The second one enables storing of the kernel log upon a normal shutdown (shutdown, reboot, halt). ๐
These parameters can be managed via the tmpfiles.d(5) mechanism, specifically the file /usr/lib/tmpfiles/systemd-pstore.conf. ๐
๐ USAGE ๐
Data stored in the journal can be viewed with journalctl(1) as usual. no special rituals required, bestie โ just the tool you already know and love ๐
๐ SEE ALSO ๐
okay that's the whole page!! you now officially understand pstore archiving ๐โจ this has been SYSTEMD-PSTORE.SERVICE(8) from systemd 262.1 โ go forth and read your kernel's dramatic little diary entries, mwah ๐
๐
๐ฆ where this page comes from
- arch rolling: systemd 262.1-1 ยท LGPL-2.1-or-later AND CC0-1.0 AND GPL-2.0-or-later AND MIT-0
- ๐ girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms