Vorta trying to fast after resume

[felixoi]

Description

After waking up from suspension vorta is instantly trying to backup, as it needs to due to my configured schedule.

1. Only connect your computer via WiFi, also allow Vorta to backup over this WiFi
2. Set the schedule to backup every two minutes
3. Put your computer in suspension
4. Wait 3 minutes
5. Wake the computer up again
6. See the error noticiations

Reproduction

• I tried to reproduce the issue.
• I was able to reproduce the issue.

OS

Manjaro 23.0.0, Gnome 44.4

Version of Vorta

0.8.12

What did you install Vorta with?

Distribution package

Version of Borg

1.2.4

Logs

2023-09-07 22:09:45,073 - vorta.scheduler - DEBUG - Got login suspend/resume notification
2023-09-07 22:09:45,073 - vorta.scheduler - DEBUG - Refreshing all scheduler timers
2023-09-07 22:09:45,076 - vorta.scheduler - INFO - Setting timer for profile 1
2023-09-07 22:09:45,077 - vorta.scheduler - DEBUG - Catching up by running job for Default (1)
2023-09-07 22:09:45,079 - vorta.scheduler - INFO - Starting background backup for Default
2023-09-07 22:09:45,080 - vorta.notifications - DEBUG - success notifications suppressed
2023-09-07 22:09:45,080 - vorta.keyring.abc - DEBUG - Only available on macOS
2023-09-07 22:09:45,082 - asyncio - DEBUG - Using selector: EpollSelector
2023-09-07 22:09:45,086 - vorta.keyring.abc - DEBUG - Using VortaSecretStorageKeyring
2023-09-07 22:09:45,086 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
2023-09-07 22:09:45,090 - asyncio - DEBUG - Using selector: EpollSelector
2023-09-07 22:09:45,098 - vorta.keyring.secretstorage - DEBUG - Found 1 passwords matching repo URL.
2023-09-07 22:09:45,103 - vorta.keyring.secretstorage - DEBUG - Retrieved password for repo ssh://REDACTED@REDACTED.com/./repo
2023-09-07 22:09:45,840 - vorta.network_status.network_manager - ERROR - Failed to get currently connected WiFi network, assuming none
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/vorta/network_status/network_manager.py", line 33, in get_current_wifi
    active_connection = self._nm.get_active_connection_info(active_connection_path)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vorta/network_status/network_manager.py", line 133, in get_active_connection_info
    connection=read_dbus_property(active_connection, 'Connection'),
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vorta/network_status/network_manager.py", line 160, in read_dbus_property
    return get_result(msg)
           ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vorta/network_status/network_manager.py", line 167, in get_result
    raise DBusException("DBus call failed: {}".format(msg.arguments()))
vorta.network_status.network_manager.DBusException: DBus call failed: ['Object does not exist at path “/”']

[real-yfprojects]

Would this be fixed if Vorta waited a few minutes before refreshing its timers?

[felixoi]

If not refreshing the timers means that no backup is being triggered, then yes. Even a couple of seconds should be enough.

[ctheune]

Happens to me, too. I'd be willing to dive into this and fix it properly at the integration level - as it's also noted as a good first issue.

[ctheune]

Ah, #2176 is already working on this and almost done. I'll hold my horses then.

[ctheune]

I accidentally referenced 2251 in an earlier comment that I deleted, not sure whether GH will remove that ... -_-

[adityakrmishra]

Hi @m3nu, I saw this was linked in the GSoC 2026 student thread yesterday! I noticed there was previous work done on this in PR #2176 and PR #2408 (which looks like a Mac-specific implementation).

Is there still an open angle on this issue that needs to be solved (perhaps for Linux/Windows network state checking)? If so, I have my local development environment fully set up and would love to tackle the remaining implementation!