search

Martchus / syncthingtray

Tray application and Dolphin/Plasma integration for Syncthing
https://martchus.github.io/syncthingtray/
Other
1.5k stars 42 forks source link

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

Open sleepmaster91 opened 4 months ago

sleepmaster91 commented 4 months ago

Relevant components

Environment and versions

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.

image

Additional context Add any other context about the problem here.

Martchus commented 4 months ago

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 commented 3 weeks ago

@sleepmaster91:

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 commented 3 weeks ago

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) image

@financelurker To answer to your questions:

financelurker commented 3 weeks ago

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?

(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 commented 3 weeks ago

I don't really remember anymore now but judging by https://github.com/Martchus/syncthingtray/issues/236#issuecomment-1983138717 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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

Maybe this issue is the same or very similar to https://github.com/Martchus/syncthingtray/issues/257#issuecomment-2082637770.

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