units: so far we defaulted to 90s as default timeout for most things, let's do so for our oneshot services too Fewer surprises, and stuff...

units: set TimeoutSec on some oneshot services Services which are not crucial to system bootup, and have Type=oneshot can effectively "hang" the system if they fail to complete for whatever reason. To allow the boot to continue, kill them after a timeout. In case of systemd-journal-flush the flush will continue in the background, and in the other two cases the job will be aborted, but this should not result in any permanent problem.

units: order sd-journal-flush after sd-remount-fs 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.

systemd-journal-flush.service: remove "trigger" from description This service is now synchronous, so "trigger" is misleading.

units: don't order journal flushing afte remote-fs.target 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.

journalctl: add new --flush command and make use of it in 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.

journal: replace implicit flushing of journal by explicit one 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.