Shell command after backup: The backup will not be completed #2120
Comments
|
Where you able to reproduce this? |
|
I experienced the same issue. Fork your post-backup commands asynchronously, i.e. surround them with (...)& The problem is that the create.py finished_event handler emits the application.py backup_finished_event before the post-backup commands are run. Consequently, the main_window.py backup_finished_event handler finds that jobs_manager.py is_worker_running() returns true, so the buttons are never toggled. (That's the worker running the post-backup commands.) Alternatively, in the create.py finished_event handler, you could just move self.pre_post_backup_cmd(self.params, cmd='post_backup_cmd', returncode=result['returncode']) up to the top, so that the commands run before the signal is emitted. Of course this would be philosophically incorrect as yes, the backup itself has indeed finished. Perhaps there should be a 'post_backup_cmd_finished' signal for main_window.py to handle before it toggles the buttons - probably not a good idea for them to be enabled whilst forked post_backup commands are still running things like fusermount -u, after a pre-backup google-drive-ocamlfuse. (One can imagine collisions if the same backup is started manually, by accident, within seconds.) |
|
Wanna add a PR for this, @mycir, since you already dissected the code it seems? If you think there is a right way to do it. |
|
Sorry @m3nu but I can't take on the responsibility of a PR at the moment - too little time for coding, my partner gets cross. A few further thoughts though: It has been said 'Qt signal is ten times slower than a virtual function'. Curious, I ran the same backup 3 times on my laptop, with the following results (time.perf_counter_ns() as ms):
So the chances of signal to slot beating async fork creation appear to be remote. Therefore, (<post-backup-commands>)& seems to be a reasonable workaround for the time being. My feeling would be to leave a 'post_backup_cmd_finished' signal as a low priority ideal. Opens a small can of worms: Timeout for stalled PBCs? If so, whether it should be hard-wired or UI configureable? Whether to take on board Kill a Python subprocess and its children when a timeout is reached ? |
|
As this command has worked in Version 0.7.6 I guess this is a regression. Why not have a look at version 0.7.6 and see, why there was no issue in this version and after eliminate the regression? |
|
@m3nu, throw a dog a bone... Contrary to my previous opinion: Leave misbehaving or interminable pre/post backup commands for the user to sort out. But at least display the PID for them to investigate. As is, GUI thread blocks when running lengthy pre/post backup commands. So I'm running calls to VortaApp.create_backup_action and VortaScheduler.create_backup in their own thread. I'm also of the opinion that the tray icon should show active whilst pre/post backup commands are running. Code ready to go, so am happy to accept a PR. PS @Golddouble, 0.7.6 fundamentally the same where the issue occurs. Guess code changes since affect event timings and you were just lucky. |
Description
When I put the following after-backup-shell-command into the field, then Vorta never comes to an end with the backup. The command is:
sleep 20 && udisksctl unmount -b /dev/disk/by-uuid/f4e0668f-b6f4-4f51-8dec-067f0ca780f7 && udisksctl unmount -b /dev/disk/by-uuid/0CD42CE5D42CD2AE && udisksctl unmount -b /dev/disk/by-uuid/2420F3B520F38BD4 && sleep 2 && udisksctl power-off --block-device $(readlink -e /dev/disk/by-uuid/f4e0668f-b6f4-4f51-8dec-067f0ca780f7| sed 's/[0-9]*$//' ) && sleep 2 && paplay /home/USER/.local/share/sounds_dawe/Fur_Vorta/pluck.wavWhat does the command do? It unmounts the external HDD, when the backup is finished and makes a sound. The issue has something to to, that the HDD is no more reachable, although I have sleep 20 at the beginning of the command.
But this command was no problem in Vorta 0.7.6 even without "sleep 20" at the beginning of the command. It has just worked in Vorta 0.7.6.
Reproduction
OS
MX-Linux 23.4 Xfce
Version of Vorta
0.9.1
What did you install Vorta with?
Distribution package
Version of Borg
1.4.0
Logs
The text was updated successfully, but these errors were encountered: