systemd 3 failed startups then the 4th success

Support
1

Need a way to figure out why syncthing fails a few times before succeeding at boot. Here is the pertinent journal logs:

Syncthing_journal
Syncthing_journal1901Ă—432 145 KB

This is happening before the syncthing logging facility is running as there is nothing in the logs from the GUI. If I add the line: ExecStartPre=/bin/sleep 9 under the Service heading it wait long enough for whatever it needs and it starts up the fist time. So how can I see what syncthing does not have if it starts up too early. I.E. what is causing these failures? Latest Raspberry pi OS.

2

Exiting without a logged reason is a bit baffling, I have no idea why that would happen.

3

Do a dmesg -T and see what log entries appear just before, during, and up until Syncthing successfully starts.

Given that it’s a RPi, I’d suspect that it might have to do storage, but there could easily be other reasons.

4

I think you are on to something. I reexamined the logs closer. Just before the 4th success:

Jul 18 18:42:19 home-pi systemd[1]: Finished NetworkManager-wait-online.service - Network Manager Wait Online.

I will modify the systemd unit file to wait for that and see what happens.

5

Yes, in your log entries, Syncthing tries to bind to eth0…

… before eth0 has been assigned an IP address 8 seconds later:

One option is to replace the symlink – e.g. ~/.config/systemd/user/syncthing.service (if running as a user service) – with a copy of the service unit file that’s been customized like so:

[Unit]
After=network-online.target
Wants=network-online.target

Systemd will hold off starting Syncthing until after the network interface is up.

6

That fixed it. Is there a way to tell the powers that be to change their default syncthing unit file or has that already been done after I installed syncthing?

7

Some Linux repos package the upstream unit file if it’s available while others roll their own.

Given the order in which services often start, it’s normally not necessary to delay starting. Based on the snippet of log entries you shared earlier, it almost looks like the DHCP lease request is taking longer than is typical.

If you’d rather not maintain a custom unit file, another option is to create a drop-in that overrides settings in the default unit file.

First, remove the custom user service unit file:

rm ~/.config/systemd/user/default.target.wants/syncthing.service

Restore the original system default:

systemctl enable syncthing --user

Create the drop-in:

systemctl edit syncthing --user

Insert the same 3 lines from my previous post, and when it’s saved, the following configuration file will be created:

~/.config/systemd/user/syncthing.service.d/override.conf

(There’s nothing special about the filename “override.conf”, it’s just the default when a name isn’t provided.)

2 Likes