| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
Otherwise we could attempt to flush the journal while /var/log/ was
still ro, and silently skip journal flushing.
The way that errors in flushing are handled should still be changed to
be more transparent and robust.
|
| |
|
|
| |
This service is now synchronous, so "trigger" is misleading.
|
| |
|
|
|
|
|
| |
Instead, only depend on the actual file systems we need.
This should solve dep loops on setups where remote-fs.target is moved
into late boot.
|
| |
|
|
|
|
|
|
|
|
| |
systemd-journal-flush.service
This new command will ask the journal daemon to flush all log data
stored in /run to /var, and wait for it to complete. This is useful, so
that in case of Storage=persistent we can order systemd-tmpfiles-setup
afterwards, to ensure any possibly newly created directory in /var/log
gets proper access mode and owners.
|
|
|
The old automatism that the flushing of the journal from /run to /var
was triggered by the appearance of /var/log/journal is broken if that
directory is mounted from another host and hence always available to be
useful as mount point. To avoid probelsm with this, introduce a new unit
that is explicitly orderer after all mounte files systems and triggers
the flushing.
|
