Syncthing Tray does not auto-reconnect after sleep when using systemd integration

[Skirmisher]

Relevant components

• [ ] Standalone tray application (based on Qt Widgets)
• [x] Plasmoid/applet for Plasma desktop
• [ ] Dolphin integration
• [ ] Command line tool (syncthingctl)
• [ ] Integrated Syncthing instance (libsyncthing)
• [ ] Backend libraries

Environment and versions

• Versions of syncthingtray, qtutilities and c++utilities: 1.0.0, 6.3.0, 5.7.0
• Qt version: 5.14.2
• C++ compiler (name and version): N/A (OBS binary package)
• C++ standard library (name and version): GNU libstdc++ 10.2.1
• Operating system (name and version): Fedora 32

Bug description I'm using the Syncthing Tray Plasmoid with the systemd integration, and Syncthing is managed by a system unit that comes with the Fedora package. The "System unit" checkbox is checked in the Syncthing Tray settings (along with the other two systemd checkboxes), and the rest of the systemd tab indicates it's working properly (status is detected, service can be started/stopped/etc.).

When resuming from sleep, Syncthing Tray notifies that it has disconnected from Syncthing. This would normally be a minor issue, but the readme describes that it should detect this case and avoid issuing a notification when using systemd integration. Moreover, it fails to reconnect automatically, despite the service still running. I must enter the "Connection" tab in the settings and press the "reconnect" button to manually reconnect to Syncthing.

Steps to reproduce

1. Enable all systemd integrations with a running Syncthing service in the Plasmoid
2. Put the system in sleep mode, and then wake it up

Expected behavior Syncthing Tray silently reconnects to Syncthing as soon as possible after waking from sleep.

[Martchus]

I've just tested it under Arch Linux and it works for me.

When resuming from sleep, Syncthing Tray notifies that it has disconnected from Syncthing. This would normally be a minor issue, but the readme describes that it should detect this case and avoid issuing a notification when using systemd integration.

There's still a timeout (15 seconds by default). So if Syncthing needs more than 15 seconds to allow Syncthing Tray to re-connect you would still get the disconnect notification.

Moreover, it fails to reconnect automatically, despite the service still running.

Well, did you configure an auto re-connect interval? Otherwise Syncthing Tray is not supposed to re-connect. That's also the case when the systemd integration is enabled. And what's status is shown for the systemd unit within the settings?

---

What's the URL you're using for that connection? The systemd integration only applies to local connections. Maybe Syncthing Tray fails to determine that the connection is local in your case. The problem could also be caused by Syncthing Tray not being able to process standby/service events correctly. Since I can not reproduce the issue myself there's not much I can do.

[Skirmisher]

There's still a timeout (15 seconds by default). So if Syncthing needs more than 15 seconds to allow Syncthing Tray to re-connect you would still get the disconnect notification.

Maybe the notification I'm getting is different then, because it always appears as soon as I resume:

Syncthing Tray - internal error
Unable to request disk events: Network session error.

Well, did you configure an auto re-connect interval? Otherwise Syncthing Tray is not supposed to re-connect. That's also the case when the systemd integration is enabled.

Frankly, setting a reconnect interval seemed like the opposite thing I wanted to do in this case—like setting a rescan interval for a Syncthing folder when inotify watching is enabled. That's the implication I got from the description in the systemd tab: "Try to reconnect when unit becomes active/running". I didn't even notice the reconnect interval setting until now. Setting it to 5000 ms does allow it to resume after sleep, though.

And what's status is shown for the systemd unit within the settings?

As I said, status reported is normal—in these cases, the service is still shown as active/running.

What's the URL you're using for that connection? The systemd integration only applies to local connections. Maybe Syncthing Tray fails to determine that the connection is local in your case.

The URL is local, just http://127.0.0.1:8080

[Martchus]

seemed like the opposite thing I wanted to do in this case

All one gets from systemd is

1. whether the service is running or not
2. and when the last wakeup (after standby) happened.

From 1. one can deduce when it makes no sense trying the auto-reconnect (service is not running) and when it makes sense to resume the auto-reconnect (service is running again). One can not tell whether Syncthing is actually already in a state where its REST-API is available. Hence there's always the need to have some sort of polling and that's the reasoning behind the auto-reconnect.

From 2. one can deduce why Syncthing has (most likely) just disconnected. That helps preventing the disconnect notification. In practice it seems that Syncthing sometimes needs a few seconds to be responsive again so the notification is even suppressed a few seconds after the wakeup. That's the "15 seconds timeout" I've mentioned earlier.

TLDR: systemd does not provide one enough information to get rid of the polling approach. It can only help to reduce polling and disconnect notifications.

---

Syncthing Tray - internal error
Unable to request disk events: Network session error.

The Network session error part looks unfamiliar. I can cross check whether I do anything "ungeneric" which therefore might not work if the concrete error is of that type.

[Martchus]

So far Syncthing Tray indeed only ignores "Connection refused" errors. I assume I have to make that code more generic. (Of course the intention was to still show errors in case of e.g. authorization problems or other errors which are not likely related to the standby wakeup.)

[Martchus]

The notification should now be avoided in case of a "Network session error" (and some other errors). I also added an explanation in the documentation why the re-connect interval is still required. I guess that's all I can do for now.

[Skirmisher]

Thanks! The clarification in the readme is appreciated.