Bug#1106681: systemd-journal-upload is restarting too quickly after a failure and enters failed state

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Tue, 27 May 2025 20:41:35 +0300 purification at ukr.net wrote:
> Package: systemd-journal-remote
> Version: 252.33-1~deb12u1
> 
> I have configured systemd-journal-upload to push system logs via
https 
> to a centralized location, however when the destination becomes 
> inaccessible (due to a network issue or a reboot of the remote host),
> systemd-journal-upload service crashes with:
> 
> May 27 17:08:20 debian-local systemd-journal-upload[1488765]: Upload
to 
> https://debian-remote:19532/upload failed: Failed to connect to 
> debian-remote port 19532 after 1 ms: Couldn't connect to server
> May 27 17:08:20 debian-local systemd[1]: systemd-journal-
upload.service: 
> Main process exited, code=exited, status=1/FAILURE
> 
> And a second later it gives up completely:
> 
> May 27 17:08:21 debian-local systemd[1]: systemd-journal-
upload.service: 
> Start request repeated too quickly.
> May 27 17:08:21 debian-local systemd[1]: systemd-journal-
upload.service: 
> Failed with result 'exit-code'.
> 
> As such, logs stop being forwarded to the destination, requiring a 
> manual restart of systemd-journal-upload.
> 
> This is likely happening due to the fact that systemd-journal-upload 
> systemd service file does not specify a RestartSec parameter, which 
> leads to it using a default value (restart after 100ms of failure),
> which in turn leads to exceeding the limit of restarts configured in 
> debian's /etc/systemd/system.conf:
> 
> #DefaultStartLimitIntervalSec=10s
> #DefaultStartLimitBurst=5
> 
> So it's possible that this issue can be fixed with something like 
> "RestartSec=20" in the systemd-journal-upload.service.

You can customize your local installation with those settings via a
drop-in, so that it works for your specific use case, which are not
necessarily right for generic usage