Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add feature to enable 'persistent' kernel logging #4

Open
mwbringmann opened this issue Feb 27, 2020 · 9 comments
Open

Add feature to enable 'persistent' kernel logging #4

mwbringmann opened this issue Feb 27, 2020 · 9 comments

Comments

@mwbringmann
Copy link

Some distros or configurations do not enable/disable persistent kernel event logging
i.e. /var/log/messages content showing events of prior boot cycles. In the event that
the system crashes, the messages file prior to the crash is thus lost. It would be useful
to add an option to reset the kernel configuration to enable persistent event logging, so
that the maximum amount of information about crashes is retained.

@sourabhjains
Copy link
Contributor

This check should be part of a new kernel logging plugin.

Comment 2 in #5

  • Sourabh Jain

@lucianochavez
Copy link

To be more specific, we keep running into issues in SLES 15 where journal log entries do not persist for previous boots, only the current boot. This is not helpful for when the user runs into a problem but reboots and then attempts to save the log.
In order to get persistent logging, there seem to be a couple of ways. According to https://access.redhat.com/solutions/696893 for RHEL, you can do
# mkdir -p /var/log/journal
if Storage=Auto is set in /etc/systemd/journald.conf.
With SLES, they say to change Storage=Auto in /etc/systemd/journald.conf to Storage=persistent and then restart the journald service with
systemctl restart systemd-journald

@sourabhjains
Copy link
Contributor

sourabhjains commented Mar 5, 2020

Thanks @lucianochavez for the detailed explanation. I think it's better to have a separate plugin to handle journald configuration and it should be a mandatory plugin and always run by default.

A quick note on the mandatory/optional plugins.
It's an upcoming feature in ServcieReport where workload-specific plugins, for example, HTX will be marked as optional. The optional plugins will not part of the default run and will require additional arguments to enable them.

@ananthmg
Copy link

ananthmg commented Mar 9, 2020

@sourabhjains
Copy link
Contributor

Thanks @ananthmg for sharing the document.

I did bit of experiments and found that we don't need two different approaches for SLES and RHEL to enable persistent journald logs.
Changing the Storage=persistent and rerunning the services is good enough to enable persistent journald logs.

  • Sourabh Jain

@sourabhjains
Copy link
Contributor

Hello @lucianochavez @mwbringmann

Do you use SystemMaxFileSize or SystemMaxFiles journald config options to limit the journald disk consumption?

If yes then please let me know your preferred values.

  • Sourabh Jain

@mwbringmann
Copy link
Author

No, I have not used these options before. Usually, I have bypassed the configuration issue and grabbed the full log files, directly.

@sourabhjains
Copy link
Contributor

This feature was dependent on the optional plugin feature in ServiceReport.

Will upstream the journalctl plugin to have persistent logging soon.

@lucianochavez
Copy link

Hi @sourabhjains

Any outlook on this enhancement? We continue to run across systems with the default in situations where the system was rebooted (due to a crash or hang or reboot test) and thus have lost error log entries from the prior boot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants