search

zocker-160 / SyncThingy

SyncThingy = Syncthing + simple tray indicator
GNU General Public License v3.0
129 stars 1 forks source link

Syncthingy Tray Icon Fails To Start On Debian 12/KDE Plasma #16

Closed RGBeezlebub closed 1 year ago

RGBeezlebub commented 1 year ago

Syncthing successfully starts and I can connect to the instance in a browser but the tray icon starts and then crashes.

image

zocker-160 commented 1 year ago

Could you please try to run this in the terminal and post the output?

Something weird is going on, because for some reason quit is being triggered.

RGBeezlebub commented 1 year ago

I ran it from the terminal and got this output:

~$ flatpak run com.github.zocker_160.SyncThingy running inside Flatpak

Using Icon: "com.github.zocker_160.SyncThingy.white" Requesting background permission... Syncthing does not seem to be running, starting own instance /app/bin/syncthing Background / Autostart permission granted quit triggered

I got to thinking about this and realized I needed to kill the running SyncThing instance and restart it by restarting SyncThingy. I tried that and got the following output and the tray icon is running.

~$ flatpak run com.github.zocker_160.SyncThingy running inside Flatpak

Using Icon: "com.github.zocker_160.SyncThingy.white" Requesting background permission... Syncthing does not seem to be running, starting own instance /app/bin/syncthing Background / Autostart permission granted

I dont know what caused the tray icon part to die but its working now.

zocker-160 commented 1 year ago

I got to thinking about this and realized I needed to kill the running SyncThing instance and restart it by restarting SyncThingy.

@RGBeezlebub could you tell me on which port that instance was running and was it the same port you have set in the SyncThingy settings?

I think there is indeed a bug going on, because SynThingy should detect an already running instance and connect to it and not trigger quit. If your syncthing instance was running on the same port, I will have look into it, because then the detection is not working properly.

RGBeezlebub commented 1 year ago

@zocker-160 SyncThing is configured to run on the default port. The orphan instance was originally launched by SyncThingy. Yes, SyncThing was running on the same port that SyncThingy is configured for.

zocker-160 commented 1 year ago

ok understood, that sounds like a bug I will have to look into.

RGBeezlebub commented 1 year ago

I was able to reproduce the bug on reboot. When logging into an X11 session syncthingy fails to start the tray icon but successfully launches the SyncThing instance in the background.

zocker-160 commented 1 year ago

I sadly cannot reproduce this issue, I have tried multiple different scenarios and for me the health check does work properly.

I wonder if there is something else going on, where the syncthing process itself actually exits for whatever reason, which then triggers an exit of the tray icon (which is intended).

I just pushed a new version, which does add a few more debug messages, it would be interesting if you could post the log of that when it fails to start and exits again.

RGBeezlebub commented 1 year ago

I just updated and will capture the debug log.

RGBeezlebub commented 1 year ago

Okay I ran SyncThingy when I had the initailly launched instance of SyncThing running to try and get it to attach and this is the CLI messages I got.

`~$ flatpak run com.github.zocker_160.SyncThingy running inside Flatpak

Using Icon: "com.github.zocker_160.SyncThingy.white" Ping endpoint: "http://127.0.0.1:8384/rest/noauth/health" Requesting background permission... reply: QJsonDocument() syncthing is not running Syncthing does not seem to be running, starting own instance /app/bin/syncthing Background / Autostart permission granted syncthing is not running quit triggered `

zocker-160 commented 1 year ago

What does http://127.0.0.1:8384/rest/noauth/health return if you open that in the browser after starting the first instance but before starting the second one?

zocker-160 commented 1 year ago

Also could you please run: flatpak run --command=syncthing com.github.zocker_160.SyncThingy as the second instance. It should show some kind of error on why it fails to launch.

RGBeezlebub commented 1 year ago

navigating to loopback renders the following output

{ "status": "OK" }

RGBeezlebub commented 1 year ago

flatpak run --command... output

$ flatpak run --command=syncthing com.github.zocker_160.SyncThingy [start] 2023/08/11 16:57:59 INFO: syncthing v1.23.6 "Fermium Flea" (go1.20.7 linux-amd64) buildbot@cncf-x86-4.flathub.org 2023-08-08 18:42:35 UTC [noupgrade] [start] 2023/08/11 16:57:59 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?) [monitor] 2023/08/11 16:57:59 INFO: Syncthing exited: exit status 1 [start] 2023/08/11 16:58:00 INFO: syncthing v1.23.6 "Fermium Flea" (go1.20.7 linux-amd64) buildbot@cncf-x86-4.flathub.org 2023-08-08 18:42:35 UTC [noupgrade] [start] 2023/08/11 16:58:00 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?) [monitor] 2023/08/11 16:58:00 INFO: Syncthing exited: exit status 1 [start] 2023/08/11 16:58:01 INFO: syncthing v1.23.6 "Fermium Flea" (go1.20.7 linux-amd64) buildbot@cncf-x86-4.flathub.org 2023-08-08 18:42:35 UTC [noupgrade] [start] 2023/08/11 16:58:01 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?) [monitor] 2023/08/11 16:58:01 INFO: Syncthing exited: exit status 1 [start] 2023/08/11 16:58:02 INFO: syncthing v1.23.6 "Fermium Flea" (go1.20.7 linux-amd64) buildbot@cncf-x86-4.flathub.org 2023-08-08 18:42:35 UTC [noupgrade] [start] 2023/08/11 16:58:02 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?) [monitor] 2023/08/11 16:58:02 INFO: Syncthing exited: exit status 1 [monitor] 2023/08/11 16:58:03 WARNING: 4 restarts in 4.179148951s; not retrying further

zocker-160 commented 1 year ago

I think I understand the issue now, but I don't know why it happens. In your initial log, the core issue is that after the ping to the endpoint it returns empty

Ping endpoint: "http://127.0.0.1:8384/rest/noauth/health"
Requesting background permission...
reply: QJsonDocument()

but it actually should be like this

Ping endpoint:  "http://127.0.0.1:8384/rest/noauth/health"
Requesting background permission...
reply:  QJsonDocument({"status":"OK"})

It then tries to run its own instance, because no other instance seems to be running but then fails to do so with WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?) and exits.

zocker-160 commented 1 year ago

I managed to reproduce the issue.

When both the background process and the tray icon get started simultaneously then the moment the health check happens, the background process is not running yet and returns nothing.

That then causes the tray icon starts its own instance, which then fails, because well the other instance is now running, which causes the second instance to return with error code 1 and trigger an exit of the tray icon.

There is not much I can do to fix this, as I cannot know that a secondary instance is currently being launched at the same time.

Enabling the autostart checkbox in the settings is all you need, it will instruct the portal to create an autostart entry for you. I feel like you are trying to manually do some autostart additionally to the setting causing this problem.

RGBeezlebub commented 1 year ago

Nope, no additional autostart settings configured for SyncThingy. Your package is the only instance of SyncThing on my device.

zocker-160 commented 1 year ago

This cannot be true though, you would not get

 [start] 2023/08/11 16:58:02 WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)

error message otherwise. There must be an instance already running and / or starting the the same time, because I highly doubt that this message is wrong, unless there is something else weird going on preventing the access of the database file. The tray icon also does not have an retry mechanism or similar, so it is not possible that it tries to start two instances at the same time.

There must be something starting it twice at the same time.

One possible option would be that you used the systemd install command (could be located in ~/.config/systemd/user) and also have an entry in ~/.config/autostart at the same time.

RGBeezlebub commented 1 year ago

I had the original instance running in the background because i thought you were working on the detection of the background instance for your applet to attach to. Please do not insist you know how my computer is configured or what I have done to it.

RGBeezlebub commented 1 year ago

Oh and don't indirectly call people liars, its incredibly rude.

"This cannot be true though, you would not get"