Martchus / syncthingtray

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

Setup wizard stuck #174

Closed xeruf closed 1 year ago

xeruf commented 1 year ago

image


Relevant components

Environment and versions

Bug description I went through the wizard, but now it has been trying for minutes to apply changes without visible progress

Steps to reproduce

  1. Run syncthingtray in terminal
  2. Click through wizard
Martchus commented 1 year ago

What happens if you click on "Show details from setup detection"? Is it always reproducible? Normally it should at least run into a timeout after a few seconds.

I've also fixed a race condition that could trigger a similar problem but it isn't part of the latest release. So you might want to try to out the Git version. (I'm not 100 % sure whether it is related to your issue. I could reproduce this race condition very often on Leap 15.4 but never on Arch Linux or Tumbleweed. It also showed up in test cases causing them to fail.)

Note that going back to re-do the setup detection is currently also broken in the latest release (and only fixed on Git).

xeruf commented 1 year ago

What happens if you click on "Show details from setup detection"?

Nothing noteworthy in there.

I will try again in a few days, with the -git version.

Martchus commented 1 year ago

Nothing noteworthy in there.

Nevertheless it would make sense to paste what's shown there. Also the absence of information can be a clue. And again, is it always reproducible?

xeruf commented 1 year ago

I was not sure whether it is a good idea to post my device ID. Maybe truncate in the dialog by default?

image

Yes, it is reproducible.

Martchus commented 1 year ago

Ok, so it had all the information needed to go on. That reduced already the number of places to look for problems. Good that it is always reproducible. That makes it much easier to verify whether improvements actually helped. I'm nevertheless wondering what the difference of your system is (compared to my systems) that makes it reproducible in the first place.

When building the syncthingtray package, did you disable tests? If not I assume the tests passed. Since the tests are exercising this exact step as well that would mean the issue is also not reproducible in your build environment (if you haven't disabled tests).

xeruf commented 1 year ago

It is persistent, even with the latest -git version :/ Tests seem to run fine.

Martchus commented 1 year ago

Good to know. Maybe I can stare a little bit more at the code this evening to find the possible mistake. (If I'd be able to reproduce the problem myself it would be much easier.)

Martchus commented 1 year ago

I didn't want to close this. I was just referencing the ticket. Well, you could try my recent changes but I don't think I have found the source of the problem yet. Likely I also won't be able to find it anytime soon. If you care to have this fixed you better start debugging this issue yourself. You're the only one I know that can reproduce the issue.

superkeyor commented 1 year ago

Martchus, thanks for your selfless contribution to the community!

Well, I had the same issue with a fresh installation of Linux Mint (I subscribed to the topic earlier). It seems this occurs after I installed the official syncthing app. If I install syncthingtray without syncthing app, I was able to go through the wizard.

Martchus commented 1 year ago

I don't know what you mean by "installed" the official Syncthing app exactly? Simply that the Syncthing executable is in PATH? That shouldn't cause the problem. I have it in PATH myself and can't reproduce the problem. In fact being able to launch Syncthing from PATH is one of the points of the wizard.

How did you install Syncthing Tray on Mint? To avoid confusing different issue, please be sure your testing against the latest version from Git master.

Martchus commented 1 year ago

By the way, which version of Boost are (all of) you using? I've noticed a similar problem myself at some point with a too old version of it on openSUSE Leap.

xeruf commented 1 year ago

the latest in the arch repos :) The annoying thing about this is that the wizard pops up at every boot, but gets stuck every time :/

Martchus commented 1 year ago

the latest in the arch repos

For the record, that would be 1.81.0. (Since issues may be open for quite a while it makes sense to be explicit about such things.)

that the wizard pops up at every boot

That is another problem of its own actually. The wizard is only supposed to show up on the first startup (like the welcome dialog box it has replaced, unless you use the CLI parameter --show-wizard or --assume-first-launch or the env variable SYNCTHINGTRAY_FAKE_FIRST_LAUNCH=1). Supposedly in your case the launched flag is never (persistently) set. I'll check on that issue but supposedly I'm also not able to reproduce (as I would have noticed it by now for sure).

Martchus commented 1 year ago

I can't reproduce the wizard popup showing every time syncthingtray is launched. If I have at least one connection configured (which you then did manually, right?) the wizard isn't showing up anymore on startup. The connection doesn't even have to be complete/valid.

Does Syncthing Tray also "forget" its other settings? I'm asking because it looks like the whole settings mechanism might not work for you. On Linux the config is normally put under $HOME/.config/syncthingtray.ini so make sure that's a writable location for the user you start syncthingtray with. I'm not reading the HOME variable literally but rely on Qt's abstraction to find the config dir so other variables may be relevant as well (see https://doc.qt.io/qt-6/qsettings.html#locations-where-application-settings-are-stored, the user-specific locations are relevant and I'm using the INI format which is under Linux identical to the native format). The code also checks whether syncthingtray.ini is in the directory next to the binary and uses that if it exists for being able to create a portable installation.

Martchus commented 1 year ago

I improved error handling of the settings handling so errors aren't completely ignored anymore. (You also need to rebuild qtutilities to test this.)

Martchus commented 1 year ago

Another user is claming that this issue has been introduced in v1.3.2 (and as such v1.3.1 has been working, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1435799307). I don't find that very likely but cannot check that myself as I cannot reproduce the issue. Do you know since when this issue occurs? It might be useful to bisect this although it may very likely just be there from the beginning (when the wizard was introduced).

xeruf commented 1 year ago

Just tested, same issue on 1.3.1

Martchus commented 1 year ago

Ok, good to know and thanks for testing. Unfortunately I still have no idea what makes your setup special so you run into this problem.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Martchus commented 1 year ago

@sten0 still wants to test this, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1627807580.

sten0 commented 1 year ago

Martchus @.***> writes:

@sten0 still wants to test this, see https://github.com/Martchus/syncthingtray/issues/175#issuecomment-1627807580.

Thank you for reopening! So I've tested a basic 1.3.2 setup on Debian 12 (bookworm, the latest stable LTS release), amd64 arch. After installing the package, logging out, and logging in again, the wizard automatically starts. Clicking through the defaults starts the Syncthing --user service, and the wizard completes.

c++utilities5 5.20.0-1 qtforkawesome1 0.1.0-1 libmartchus-qtutilities6 6.10.0-1 Qt 5.15.8-2 Boost 1.74.0+ds1-21 KDE Plasma 5.27.5

I'm not sure if it's relevant, but this is with Debian-provided Syncthing packages.

It might take a month or more to update all the dependencies, but I'll test the latest version of everything soon to test if this issue exists in a user-facing way on amd64. Then I'll enable CI and see if it still holds up on other archs. 'hopefully everything will be fine! :)

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.