search

borgbase / vorta

Desktop Backup Client for Borg Backup
https://vorta.borgbase.com
GNU General Public License v3.0
2k stars 133 forks source link

Long running pre-backup commands freeze UI #210

Open schwma opened 5 years ago

schwma commented 5 years ago

Describe the bug I was trying to add a random delay of 0-59 minutes per backup using the pre-backup command option. To do so I used the following command: sleep $[ $RANDOM % 60 ]m, but unfortunately while pre-backup commands are running, the Vorta UI freezes. This probably won't be an issue for most scripts, but will be a problem in cases where scripts take a long time to compete.

To Reproduce Steps to reproduce the behavior:

  1. Open Vorta -> Schedule -> Shell Commands
  2. Enter a long running command as a Pre-backup command, such as sleep 1m
  3. The Vorta UI will stop responding while the command is running

Desktop (please complete the following information):

m3nu commented 5 years ago

Interesting, since the pre/post-backup command runs in its own thread. Will test.

schwma commented 5 years ago

I just tested the pre-/post-backup commands in Vorta 0.6.10 and only the pre-backup command seems to freeze the UI. I assumed it extends to the post command as well, but it does not.

m3nu commented 5 years ago

That makes sense actually. The pre-backup command is run when preparing the backup. So it runs in the main thread. (I gave the wrong info just before.)

The reason for this is to allow checking for certain conditions. E.g. the right network. If the returncode is not 0, it will cancel the backup.

I also noticed that the UI only blocks if the backup is started by the user. It doesn't block when the backup is started by the background scheduler.

So I see those options to improve the behavior:

  1. Don't run pre-backup command when user starts backup himself + note about this next to the pre-backup field.
  2. Add logging message that pre-backup command is now running before actually running it. So user knows whats going on. UI will still freeze.
  3. Refactor to run pre-backup command in a separate thread, like the main Borg-command.
ThomasWaldmann commented 5 years ago

I wouldn't limit pre-backup to "checking conditions". Often this is used to bring the data into a backup-worthy state (like dumping an active database, doing a snapshot, etc.) and this obviously must always run, no matter whether started manually or automatically. So option 1 is out of question.

3 sounds like the best option.

m3nu commented 5 years ago

3 it is then.

samuel-w commented 3 years ago

They are also uncancellable, while blocking other actions such as repo checking.

real-yfprojects commented 2 years ago

I would try to have an own PreBackupJob inheriting JobInterface or BorgJob and scheduling the BorgCreateJob in its finished_event method, while BorgCreateJob schedules the PostBackupJob. Though this is not as simple as I described it here since the jobs must run right after each other.

sunhasgothishaton commented 2 years ago

I have a pre backup script which takes a few minutes. It took me a while to realise that the UI had froze, without any notification that it was running.

I know in the long term it would be good to implement option 3. Would it be possible, for the short term, to implement option 2 as this would allow me (and other users) to see that the backup (and pre backup script) is running, while the UI is frozen.