Can't restart syncthing from the tray - Only works when "Apply and launch now" from Startup settings

[sleepmaster91]

Relevant components

• Standalone tray application (based on Qt Widgets)
• 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.5.0
• Qt version: ….….…
• C++ compiler (name and version): …
• C++ standard library (name and version): …
• Operating system (name and version): …

Bug description
A clear and concise description of what the bug is.
When restarting Syncthing from the tray Syncthing won't restart causing SyncThingTray to not reconnect

Steps to reproduce

1. Click on tray icon
2. Click on "restart syncthing" icon

Expected behavior
A clear and concise description of what you expected to happen.
Syncthing restarting and reconnecting

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

[Martchus]

It works for me. Did you configure the re-connect interval accordingly? Note that the default re-connect interval is 30 seconds so you might be to impatient (or want to tweak the interval). It may run into "Connection refused" if Syncthing doesn't come up quick enough. When using the internal launcher¹ or Systemd-integration the error can be suppressed in this case by setting a grace period in the notification settings. Otherwise you cannot avoid the error except by disabling those errors completely.

¹ Maybe restarting Syncthing via the API - as the "Restart Syncthing" action does - does not count as restart when using the internal launcher because Syncthing's monitoring process is actually nevertheless constantly running. Then the "Connection refused" error also cannot be suppressed.

---

Maybe I should tweak default settings to disable showing notifications for this kind of error by default (as it cannot be suppressed reliably in all cases).

[financelurker]

@sleepmaster91:

• Have you ever run into that error again?
• Can you actually access the HTTP UI of the underlying syncthing service after the restart? (I guess the default is http:127.0.0.1:8384 ) - from your error description I cannot infer if your syncthing is actually running/restarted or not...
• Can you see that syncthing was actually restarted? I guess reading the syncthing logs could help here...
• Did the message disappear after a while?

Interestingly enough (I never tried it, but here we are...) I also get the error, when restarting syncthing through the syncthingtray application - but it quickly disappears again and syncthingtray app is happily connected again to the backend. But I guess that's because of the default, @Martchus mentioned.

I am new to being involved to FOSS, but since there was no feedback ever again, since early March when the ticket was created, I guess it's not that big of a deal? (in my day-time job this would be a triage candidate 😁)

[sleepmaster91]

Hi @Martchus
I tried lowering the interval to 20 seconds but it doesn't seem to change anything. I usually got these error after the automatic upgrade so I addes the --no-upgrade flag in the command parameters and it seems to run fine since (it starts fine after a system restart)

@financelurker To answer to your questions:

• The issue is still present (no longer getting the error messags though but I still have to manually click on "Apply and Launch now" from the startup settings for the folder to sync again)

• I can access the default URL after restarting syncthing with the button mentioned above but not when restarting syngthging with the restart button from the tray

• Sometimes the syncthing try icon will turn gray and sometimes it will stay green but lose connection until I manually restart syncthing here's what the logs say when restarting from the tray
  

• Haven't had the message appear so I can't know for sure

[financelurker]

Okay... that all sounds odd... Since, regarding to the code of this syncthingtray project, it restarts syncthing by calling it's REST API. I would guess that for the monitor process it should make no difference who is calling that endpoint (since the native syncthing web UI is calling the same REST endpoint, according to my browser developer tools/"Network" tab).

"Syncthing crashed with exit code 3" - there is an almost decade old issue (that is closed) that explains that error code 3 should be handled by the syncthing monitor process as indicator to restart the main process of syncthing again.

Have you tried updating all versions?

• syncthing is 1.27.8 (as of 4th of June)
• syncthingtray 1.5.4 (also as of 4th of June)

(The thing is: I wouldn't be able to dig deeper, since you're facing these issues on a windows machine and I cannot reproduce it on my linux machine, with systemd as monitor process... - and I am not sure what the actual code of that monitor process for windows looks like)

[Martchus]

I don't really remember anymore now but judging by #236 (comment) I have already tried to reproduce the problem but couldn't reproduce it. I guess I can try to reproduce it again under Windows next time I boot Windows.

[Martchus]

I tested it again and I could reproduce it. The disconnect is not happening immediately. It only happens after the long-polling connection times out (by default after a minute). Maybe I wasn't patient enough to wait for the long-polling connection to time out in my previous tests. In my tests it helps to click on the "Connect" button on the tray to connect again - just the automatic re-connect interval is not effective.

The problem is not reproducible when the checkbox for considering the launcher status for re-connects is not checked. So this feature is probably interfering.

I also noticed that the restart via the web UI doesn't work when using the built-in Syncthing library. Probably also something to improve.

[Martchus]

GitHub closed the ticket automatically. The referenced commit will also probably fix this issue for you (unless there are even more problems in your case). You can reopen the ticket if something is missing.

[sleepmaster91]

hi @Martchus thank you for the update
However i'm not familiar with commits do I need to compile the code myself ? If so how ?
Thank you for your help !

[Martchus]

I created a Windows build you can download directly from my build server: https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-syncthingtray-qt6-1.5.5-1-any/x86_64-w64-mingw32/bin/syncthingtray-qt6-static.exe

I haven't tested it on Windows myself yet.

[Martchus]

Looks like it still doesn't work. It probably only worked in my previous tests because I used a test instance that was very quick to start.

[Martchus]

Maybe this issue is the same or very similar to #257 (comment).

Unfortunately I cannot reliably reproduce the problem which make it hard to test any fixes. I pushed another commit that might help.