search

Martchus / syncthingtray

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

Repeated synthingtray error notifications even though "don't reconnect when unit is not active/running" is selected #179

Closed VorpalBlade closed 11 months ago

VorpalBlade commented 1 year ago

Relevant components

Environment and versions

Bug description I have a script that starts the system service syncthing@user.service only when connected to a specific SSID and when on AC power. This has worked fine for nearly a year. Syncthingtray would display an error notification when syncthing was stopped, and that was that.

However after recent upgrade (last couple of months, sorry I have been slow to getting around to reporting this) syncthingtray started showing repeated popups of the same error:

Request URL: http://arvid:@127.0.0.1:8384/rest/system/config
[2023-04-03T11:09:19] Unable to request Syncthing config: Connection refused

This shows up every 10 seconds or so.

For my purposes, the old behaviour (one time error) was much preferable.

It appears that syncthingtray is now ignoring this setting: image

Steps to reproduce

  1. Use systemd unit (system level) with monitoring enable
  2. Stop systemd unit
  3. Get unexpected notifications

Expected behavior No notifications

Screenshots image

Additional context Add any other context about the problem here.

Martchus commented 1 year ago

From the looks of it the systemd intergration has been setup correctly. That connection attempts are not suppressed while Syncthing is not running is then a bug, indeed. However, I cannot reproduce the problem on my system. Actually, I can reproduce the opposite: Even though Syncthing is running, re-connect attempts are suppressed (at least when one manually stops and starts Syncthing while Syncthing Tray is running). So there must be something wrong in the code (which I haven't touched recently).

VorpalBlade commented 1 year ago

Re-connect attempts are suppressed (at least when one manually stops and starts Syncthing while Syncthing Tray is running)

That seems to work just fine for me. Perhaps the code can get "stuck" in either state?

Martchus commented 1 year ago

At least not on the level of the SyncthingService class because at least in my case the unit's state is shown correctly in the settings. Do in your case the settings also show the correct state of the unit? If not, then this is a bigger problem which can can definitely not reproduce on my system.

VorpalBlade commented 1 year ago

The settings are out of sync for me. Here the service is not actually running:

image

VorpalBlade commented 1 year ago

Also hitting the stop button (and providing the correct password) does not change this at all.

What did change things was the KDE taskbar crashing and restarting, a few seconds after I typed the above line... Now it shows as "inactive - dead". And the issue is gone for now, everything seems to be properly in sync (In other words: I cannot reproduce the issue any more right now, however I have seen it several times over the last few months, so it can get into the state somewhat repeatedly).

Does the plasmoid code run in the taskbar process?

Martchus commented 1 year ago

Does the plasmoid code run in the taskbar process?

Yes, unfortunately that's the architecture chosen by KDE devs. I cannot change this. This means if you want to "reset" the Plasmoid you need to invoke killall plasmashell && plasmashell.

Likely in your case the SyncthingService object is stuck, indeed. Either a bug of that class itself or a bug of Qt DBus or systemd's D-Bus interface or the D-bus daemon itself. This will be very hard to sort out. I'm not sure whether I can help here much without being able to reproduce the issue myself. Note that I haven't changed much recently in the SyncthingService class so my implementation is unlikely to have introduced this regression.

Martchus commented 1 year ago

Just for the record, that's the fix for the "opposite" issue I mentioned I could reproduce: https://github.com/Martchus/syncthingtray/commit/f524a18b8327de8e111d58c3828e3db7d715eb00

Of course this won't help with the issue you are having. I'll check whether I can spot some mistake in SyncthingService regarding your issue.

Martchus commented 1 year ago

I might have found a problem which might be the source of your issue. Strange that GitHub closed the issue after pushing a commit that references the issue. I actually wanted to ask whether you can try to verify whether it actually helps.

VorpalBlade commented 1 year ago

I believe github closes the issue upon merging/pushing to the main branch if you use the wording `fix/fixes #".

I have seen the issue a few times this year. So I can (tomorrow) try to build with that patch. However I don't know how to get it into that stuck state. It just happened after the laptop had been on for a few days. Also: it is a laptop I will only have for a couple more weeks, as I will soon change workplace.

Do you have any ideas for how to get into the state?

Martchus commented 1 year ago

Do you have any ideas for how to get into the state?

To trigger the same symphtom you're describing one needed to make systemd's D-Bus interface propagate the ActiveState and SubState in one go for a transition from the unit being effectively running to being effectively not running anymore. I'm not sure how to do that except for artifically mocking the D-Bus interface completely. That's likely not very useful, though. It would allow me to verify that my fix works as intended (which I'm already quite sure about) but not that my fix actually tackles the underlying problem in your case (which might be a different one that just leads to the same sympthom).

Since you cannot reproduce the issue very reliably yourself I guess the best one can do is applying the change, let some time pass and see.

VorpalBlade commented 1 year ago

I have now upgraded to 1.4.1-1, and rebooted since that upgrade. However the issue just triggered again, so it is not fixed unfortunately.

Martchus commented 1 year ago

So there's a different underlying issue in your case. I suppose I can only go though the code again to spot further mistakes.

In https://github.com/Martchus/syncthingtray/issues/179#issuecomment-1494108457 you wrote:

The settings are out of sync for me.

If you change the service name in the settings and then change it back, does it then show the state correctly? If it still appears stuck then there must be a bigger problem with the usage of Q D-Bus or that module itself. Otherwise it is likely just a particular state change that is not processed correctly (the problem could of course still be on all levels).

VorpalBlade commented 1 year ago

If you change the service name in the settings and then change it back, does it then show the state correctly?

Yes, this works, and I don't even need to save the settings for it to take effect.

Martchus commented 1 year ago

Ok, I suppose that's good. And yes, the service name is evaluated while typing so not having to save settings is expected (and in fact wouldn't normally help alone).

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.

VorpalBlade commented 1 year ago

Well, I don't know if it is stale. I don't have that computer with that setup any more. So I'm not likely to hit this. That said, it could absolutely still be an issue as far as I know.

Martchus commented 1 year ago

If an issue is marked as stale and eventually closed due to that this does not mean the issue is resolved. It just means that no progress has been made for a while and it is unfortunately unlikely that further progress is made any time soon. We can keep this open a little bit longer but in general it makes sense to close such tickets at some point. Tickets can also always be re-opened :-)

stale[bot] commented 11 months 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.