[enhancement] [callback] add level 9 - all done

[kdupke]

I learned to use the callback script to wake-on-lan the backup system, but miss a hook to power off the backup system after backup.

The last cal to the callback script is level 8, but this is before umount so I can't use it for poweroff.

That said I appreciate a callback level 9, when all is done just before or after releasing all stuff.

[Germar]

What about starting your shutdown command detached with a delay of 30sec?

[kdupke]

That is the workaround I'm using at the moment. But it does not handle errors very well.
It isn't a clean solution.
Looking at the code it looks like there is an 'unlock' at the end of the backup, which could be the point of the callback.release entry. Unfortunately I never did python yet, else I could propose code.

[kdupke]

Just in case, today I tried to change the time of daily backup. I started backintime-qt4, opened the config dialog and tried to change the time.

However, when I open the config dialog it calls the callback on level 7 and when clicking OK it calls callback with level 8.

So both are not really suitable for a WOL and Powerdown. Level 7 does not harm as it wakes up a server already up. But level 8 is bad as it calls the delayed shutdown while backintime is still up.

Conclusion: backup power management needs separate treatment.

[Germar]

Hmm. So we would also need to check if either GUI is showing that profile or a snapshot for the profile is still running before launching that new callback event...

[kdupke]

Not really. Might be the idea of using user-callback for this feature isn't the right thing.

Or the handling within the GUI could be enhanced.

Let me start more basic, think about a remote server not available before powering on.

If I start the GUI, then I might not need the remote system because I want to change the config, or just check something.

So the process could be:
GUI:
Start GUI, load local data, ask if the remote data (aka backups) should be loaded, if so start the remote system. If not, then only display what's local. Of course starting remote could be automated, showing a message 'starting remote' (of course, start up needs some time, a 'just user' could assume something is wrong).

If I change something which has to be stored on the remote (AFAIK config change, right?), and the remote isn't available, ask for starting remote and wait for it to be done.

After all, when I leave the GUI and the remote was powered on, then power it off.

As for the command line this is much easier, right? Some of the commands need the remote to be available, in which case the remote needs to be powered on. And if powered on then power it off at the end (using callback does not really works because of the way subshells are handled and waited for an SSH to finish).

That said, might be the idea of using callback to fulfill remote power management is wrong?

[Germar]

Yeah, I already have plans for making a new mode for custom mount commands. This will use the same method to recognize in-use mounts like the other modes already do. user-callback isn't the right place for this either.

But for GUI the remote MUST be available. Pressing OK in Settings will always result in a check of the new config which will fail if the destination is not available. Also you will not see anything useful without destination in the main window. No snapshots, no logs, no files...

Just imagine opening and closing GUI while a new snapshot is running. This would shutdown the remote host while the snapshot is still running. That's why we need to check if any process is still using the remote host. And this has to work even for different profiles (two or more profiles could use the same remote host).