I came to the same conclusion as Daniel Povey in Message #56.
RestartSec in systemd-journal-flush does not help in this case. it is a
one-shot service and it will not be restarted.
Note that in my case systemd-journald is killed due to a watchdog timeout when
the server is under heavy load.
As
To follow up: this did not fix the problem.
On Fri, Oct 21, 2016 at 2:45 PM, Daniel Povey wrote:
> I just want to follow up on this that I believe I have found the reason
> for this bug and I have a solution which I am testing out.
>
> In the output of `systemctl status systemd-journald` it says
I just want to follow up on this that I believe I have found the reason for
this bug and I have a solution which I am testing out.
In the output of `systemctl status systemd-journald` it says:
Active: failed (Result: start-limit)
and this is related to the systemd mechanism to stop cycles where
Another observation about this bug, which might be helpful.
If the signal is sent to systemd-journald via
/bin/systemctl kill --kill-who=main --signal=SIGUSR1
systemd-journald.service
then messages like the following show up in the kernel messages from `dmesg
-T`, like:
[Sat Oct 15 21:02:35 2016]
I just want to report that we are suffering from this bug, and it is quite
frequent.
This is with version 215-17+deb8u5 .
root@a12:~# systemctl status systemd-journald
*** systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Act
