On 22 February 2018 at 21:11, Bryan Quigley <bryan.quig...@canonical.com> wrote:
> Sorry, yea, I meant our defaults, not the journal config options itself.
> SystemMaxUse= is unset in the config in bionic (although it's all commented
> out, but I believe that's supposed to indicate our defaults?)
> Re:disk writing. I don't disagree, but if we are SRUing it we need to
> consider that more. For 18.04 we can still decide to remove rsyslog to
> reduce the impact, we can't do that for 17.10/16.04.
Current situation of non-persistent logs imho is critical bug. It has
a severe impact, data loss, on a large portion of Ubuntu users.
To reduce duplication, one of the suggestions was to still forward
messages to rsyslog (for forwarding) but do not store those that are
coming from journald on disk, as journald already has them one disk.
Alternative, is to switch to syslog-ng with journald module such that
it pulls in rich journal messages into syslog, and make journald stop
forwarding messages to syslog.
Another alternative is to drop rsyslog from default install, and make
journald be the default syslog provider on Ubuntu.
I am undecided on how to best implement de-duplication of a portion of
messages in Ubuntu going forward, but above are three technically
plausible paths to solve this.
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
systemd journal should be persistent by default: /var/log/journal
should be created
Status in systemd package in Ubuntu:
Status in systemd source package in Xenial:
Status in systemd source package in Zesty:
Status in systemd source package in Artful:
Status in systemd source package in Bionic:
* System logs are lost across reboots because they are not stored
* Fresh installations, or upgrades to this version of systemd, should create
/var/log/journal and trigger automatic persistent logs.
* Users may choose to remove said directory, or disable persistent logging
* Persistent logging by default will cause logs to be flushed from
/run to /var/log, meaning there will be less RAM used (/run is tmpfs
backed), but increased disk usage (in /var/log). The journald daemon
has limits set for logs, meaning they will be rotated and discarded
and should not cause out of disk-space errors.
* Original bug report
After upgrading 14.04 -> 16.04, key services are now running on
systemd and using the systemd journal for logging. In 14.04, key
system logs like /var/log/messages and /var/log/syslog were
persistent, but after the upgrade to 16.04 there has a been a
regression of sorts: Logs sent to systemd's journald are now being
thrown away during reboots.
This behavior is controlled by the `Storage=` option in
`/etc/systemd/journald.conf`. The default setting is `Storage=auto`
which will persist logs in `/var/log/journal/`, *only if the directory
already exists*. But the directory was not created as part of the
14.04 -> 16.04 upgrade, so logging was being lost for a while before I
realized what was happening.
This issue could be solved by either creating /var/log/journal or
changing the default Storage behavior to `Storage=persistent`, which
would create the directory if need be.
## Related reference
* `systemd` currently compounds the issue by having ["journal --disk-usage"
report memory usage as disk
usage](https://github.com/systemd/systemd/issues/4059), giving the impression
that the disk is being used for logging when it isn't.
* [User wonders where to find logs from previous boots, unaware that the
logs were thrown
## Recommended fix
Restoring persistent logging as the default is recommended.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~touch-packages
Post to : email@example.com
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp