Re: [systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

2019-06-10 Thread Eric DeVolder

Hi Lennart,
I've applied the coding style guidelines, and created a pull request 
#12768 via GitHub. Let me know what I may have done wrong, my first 
attempt via GitHub.

Thanks,
eric

On 5/16/19 9:34 AM, Lennart Poettering wrote:

On Do, 16.05.19 09:28, Eric DeVolder (eric.devol...@oracle.com) wrote:

Could you please submit this via github as PR? Review is so much nicer
there, in particular for complex patch sets, and this qualifies as
complex I think. This also has the benefit that the code is
automatically analyzed by our CI tools.

https://github.com/systemd/systemd/pulls

Moreover, please make sure to to read our coding style guidelines
here:

https://systemd.io/CODING_STYLE

Form a very brief glance it appears the code doesn't follow formatting
rules for example.

Thanks!

Lennart

--
Lennart Poettering, Berlin


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

2019-05-16 Thread Eric DeVolder

OK, will do!
eric

On 5/16/19 9:34 AM, Lennart Poettering wrote:

On Do, 16.05.19 09:28, Eric DeVolder (eric.devol...@oracle.com) wrote:

Could you please submit this via github as PR? Review is so much nicer
there, in particular for complex patch sets, and this qualifies as
complex I think. This also has the benefit that the code is
automatically analyzed by our CI tools.

https://github.com/systemd/systemd/pulls

Moreover, please make sure to to read our coding style guidelines
here:

https://systemd.io/CODING_STYLE

Form a very brief glance it appears the code doesn't follow formatting
rules for example.

Thanks!

Lennart

--
Lennart Poettering, Berlin


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

2019-05-16 Thread Lennart Poettering
On Do, 16.05.19 09:28, Eric DeVolder (eric.devol...@oracle.com) wrote:

Could you please submit this via github as PR? Review is so much nicer
there, in particular for complex patch sets, and this qualifies as
complex I think. This also has the benefit that the code is
automatically analyzed by our CI tools.

https://github.com/systemd/systemd/pulls

Moreover, please make sure to to read our coding style guidelines
here:

https://systemd.io/CODING_STYLE

Form a very brief glance it appears the code doesn't follow formatting
rules for example.

Thanks!

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

2019-05-16 Thread Eric DeVolder
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:
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
 - lists the files in the pstore (eg. /sys/fs/pstore)
 - for each file, locates a handler for the type of file (eg. dmesg, MCE, etc)
 - invokes the handler for the file (eg. the handler appends file to a list)
 - when the list of files is exhausted, all handlers are notified; in the case
   of the dmesg handler, final processing of the files occurs:
   - files sorted 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 either moved to archive storage or recorded in the journal
   - 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 root0 May  9 09:50 .
 drwxr-xr-x 7 root root0 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 root40 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