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 a workaround, I set "Type=notify" (instead of the default "Type=simple") in systemd-journald's [Service] section . I assume it should delay systemd-journal-flush.service until systemd-journald is ready to handle the signal. Worst case scenario : systemd-journald does notify that it has started before installing the signal-handler. Then the workaround would only minimize the effect and I guess it would be an upstream bug. But to stay on the safe side I also added these settings to give systemd-journald a chance to restart at a latter time (still in the [Service] section): # wait 5s at restart. # fails if restarted more than 100 times within 10mn RestartSec=5 StartLimitBurst=100 StartLimitInterval=600 Finally I increased WatchdogSec in order to be more tolerant to high load but I think it is out of the scope of this bug. _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
