On Di, 15.01.19 11:23, Eric DeVolder (eric.devolder@xxxxxxxxxx) wrote: > Systemd-devel, > > Below is a write-up I've done to explain a new service for archiving pstore > contents. I've attached the pstore.service files > (/lib/systemd/system/pstore.service and bin/pstore-tool). These are trivial > right now, but easy to build upon if periodic, rather than just on-boot, > examination of the pstore is desirable. If you look at the TODO list in our git tree, you'll find that importing and flushing pstore has been a long-time TODO list item for us. Our original idea was to make this another input for the journal, but as I understand these days the pstore files are not necessarily in log format, hence maybe handling it similar to coredumps is an option too. i.e. drop it into some directory in /var like we do it for /var/lib/coredump/, and then link that up with the journal through some structured log message. So yeah, it appears to me that you have similar ideas there. And yes, we'd welcome such work. ACPI is generic and standard enough to make this generically useful, and the code for this is simple enough hence I think this sounds like something acceptable for our tree. That said, I wonder what else is generally found in pstore these days, besides the dmesg stuff? i.e. is there well-known other stuff, such as firmware stuff? > The questions I have for you are: > > - Is a new unit pstore.service the right approach for this? If not, what > unit do you recommend augmenting with these actions? Well, our own code is usually placed in service units whose name begins with "systemd-", hence systemd-pstore.service sounds more systematic. But yeah, by all means, please submit a proposal as PR. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel