commit | 19672b669d23fffd7361449eb7af25f1381fcfdb | [log] [tgz] |
---|---|---|
author | Andrew Geissler <geissonator@yahoo.com> | Wed Feb 07 12:33:02 2018 -0600 |
committer | Andrew Geissler <geissonator@yahoo.com> | Wed Feb 28 12:19:39 2018 -0600 |
tree | 031b89aae987afaece3679788307489ef5a32468 | |
parent | 10eee9b9f26b31ffdd4094569b1541d5acabafc1 [diff] |
Script to parse journalctl json output This was a quick script written by Brad that I find quite useful and therefore good candidate for our openbmc tools repo. It takes the "journalctl -o json-pretty -r" output which is collected in a lot of BMC FFDC and formats it into the normal journalctl output we're all used to. The json output is collected because it contains all of the metadata, which is sometimes needed for debug but it's very difficult to look at when trying to isolate down to an issue. Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
The goal of this repository is to collect the two-minute hacks you write to automate interactions with OpenBMC systems.
It's highly likely the scripts don't meet your needs - they could be undocumented, dysfunctional, utterly broken, or sometimes casually rm -rf ~
. Don't even think about looking for tests.
You have been warned.
Then this repository aims to be the default destination for your otherwise un-homed scripts. As such we are setting the bar for submission pretty low, and we aim to make the process as easy as possible:
However you want to send patches, we will probably cope:
Look, the rm -rf ~
thing was a joke, we will be keeping an eye on all of you for such shenanigans. But so long as your patches look sane with a cursory glance you can expect them to be applied. To be honest, even Perl will be considered moderately sane.
We don't ask for much, but you need to give us at least a Signed-off-by, and put your work under the Apache 2.0 license. Licensing everything under Apache 2.0 will just hurt our heads less. Lets keep the lawyers off our backs. ^
^ Any exceptions must be accompanied by a LICENSE file in the relevant subdirectory, and be compatible with Apache 2.0. You thought you would get away without any fine print?
Probably with difficulty. Don't expect the layout to remain static, or scripts to continue to exist from one commit to the next.