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

[VorpalBlade]

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.3.3-1, 6.11.0-1, 5.21.0-1
• Qt version: 5.15.8
• C++ compiler (name and version): gcc (GCC) 12.2.1 20230201
• C++ standard library (name and version): libstdc++ (gcc-libs) 12.2.1-2
• Operating system (name and version): Arch Linux

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:

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

Additional context
Add any other context about the problem here.

[Martchus]

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]

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]

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]

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

[VorpalBlade]

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]

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]

Just for the record, that's the fix for the "opposite" issue I mentioned I could reproduce: f524a18

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]

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]

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]

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]

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]

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 #179 (comment) 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]

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]

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]

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]

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]

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]

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.