Set journald to persist logs #11

New Issue

raucao · 2019-01-26T11:22:03Z

raucao commented

2019-01-26 11:22:03 +00:00

I manually set Storage=persistent instead of auto in /etc/systemd/journald.conf just now, but I think that should be done as part of the base recipe. Can't think of a situation where we'd want to throw away logs like that.

I manually set `Storage=persistent` instead of `auto` in `/etc/systemd/journald.conf` just now, but I think that should be done as part of the base recipe. Can't think of a situation where we'd want to throw away logs like that.

raucao commented

2019-05-28 10:52:25 +00:00

This is still an issue. It was reset at some point on andromeda, and never added on barnard.

greg commented

2019-05-28 11:52:21 +00:00

I checked and it doesn't appear to be an issue. From the docs:

Storage=

Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto".

Barnard has journal files under /var/log/journal/aa5e5810d9954df09c012672093c2db6/ dating back to Apr 21. I checked on our other Ubuntu 18.04 servers, they do have a /var/log/journal/ folder so the default persists the logs to disk.

Is there something I'm missing?

I checked and it doesn't appear to be an issue. From the [docs](https://systemd.network/journald.conf.html): > Storage= > > Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" is similar to "persistent" but the directory /var/log/journal is not created if needed, so that its existence controls where log data goes. "none" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "auto". Barnard has journal files under `/var/log/journal/aa5e5810d9954df09c012672093c2db6/` dating back to Apr 21. I checked on our other Ubuntu 18.04 servers, they do have a `/var/log/journal/` folder so the default persists the logs to disk. Is there something I'm missing?

raucao commented

2019-05-28 11:55:32 +00:00

Is there something I’m missing?

Yes, the logs were empty when I tried to check them using journalctl, which is the reason why this issue exists in the first place, and why I went and fixed it for that one machine.

> Is there something I’m missing? Yes, the logs were empty when I tried to check them using `journalctl`, which is the reason why this issue exists in the first place, and why I went and fixed it for that one machine.

greg commented

2019-05-28 12:00:45 +00:00

I don't understand, the logs wouldn't be "empty" even if they were explicitly set to volatile, they would still be stored in memory (which they were not before you changed that setting, since the default is auto, which persists them to disk)

raucao commented

2019-05-28 12:05:56 +00:00

They were gone after a reboot. Then I looked at the docs and it seemed like they were indeed only stored in memory until I changed it. That's all I know, and it was definitely broken when I created the issue.

greg commented

2019-05-28 12:25:11 +00:00

I think we can close this, as the journald logs on barnard go back further than the last reboot (12 days ago)

raucao commented

2019-05-28 12:49:20 +00:00

OK.

raucao closed this issue

2019-05-28 12:49:20 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#11