Back In Time

Run action after backintime completes

Asked by Sparhawk

I use xautolock to suspend my laptop automatically. In the past, I've run the following command to backup.

    xautolock -disable; time sudo nice -n 19 ionice -c2 -n7 backintime --checksum --backup-job; xautolock -enable

I've since upgraded to backintime 1.1.0 (in Arch Linux), and I notice that backintime now terminates immediately. That is, it drops me back to the command line (presumably after running `xautolock -enable`) immediately after running the command, while backintime/rsync runs in the background. Is there a way to run a command only after backintime completes the backup?

Alternatively, I notice that backintime says
    WARNING: Inhibit Suspend failed.
so perhaps xautolock could be supported internally?

Question information

Language:
English Edit question
Status:
Solved
For:
Back In Time Edit question
Assignee:
No assignee Edit question
Solved by:
Germar
Solved:
Last query:
Last reply:
Revision history for this message
Best Germar (germar) said : 		#1

I changed 'backintime --backup-job' to detach from terminal. It's the same as running 'backintime --backup &'.
This was necessary after I included anacron-like schedule functions into BIT. The Udev rule schedule wouldn't work otherwise.

'--backup-job' is supposed to be used in cronjobs. You can use 'backintime --backup' to keep backintime running in foreground.

I don't know xautolock, but I included a DBus call that will prevent your system from going into suspend or hibernate in the same way a movie player (e.g. VLC) does. If it doesn't work this is most likely because it couldn't connect to DBus Sessionbus. Check $DBUS_SESSION_BUS_ADDRESS environ variable.

Let me mention two other things on your line:
1. you shouldn't use 'sudo' because this will set wrong $HOME environ. Take a look at the difference between 'sudo env | grep ^HOME' and 'gksudo env | grep ^HOME'
2. using '--checksum' for every new snapshot is a bit overkill in my mind. It will take ages and uses lot more system resources. In https://answers.launchpad.net/backintime/+faq/2445 I've written down a way to run this e.g. only once a month.

Revision history for this message
Sparhawk (sparhawkthesecond) said : 		#2

Thanks for the clarification. I always wondered about the difference between `--backup-job` and `--backup`. I had used the former in the past, since my backup commenced after a USB drive was connected, and it seemed "cron-like" to me, but using the latter now makes more sense.

Regarding the DBUS call:
    $ echo $DBUS_SESSION_BUS_ADDRESS
    unix:abstract=/tmp/dbus-V0mtR6iUBt,guid=933a647c5c0784a9dab7682054c80a6d
I'm not sure what I should be seeing.

1. Both commands return `HOME=/root`. I take your point though. However, I think this is moot, since I backup `/`, and keep the config in root's home.
2. I actually *do* run this manually once a month. Daily, I run it without checksum.

Thanks for the rapid and clear response, once again, and thanks for the extra comments.

Revision history for this message
Germar (germar) said : 		#3

Back in the days where BIT didn't have profiles and used schedules per include folder there was a 'real' difference between --backup and --backup-job (don't ask me for details, I don't remember). After that there were no difference for long time.

By now --backup will (in opposite to --backup-job):
- run in foreground
- force take a snapshot even if on battery
- force take a snapshot even if anacron-like schedule would prevent this

The DBus address looks fine. But this is for your unprivileged user, isn't it? Try 'sudo env | grep ^DBUS'. I guess that will return an empty line. I'm not sure how to handle that. Root would only have a SessionBus if you login into e.g. Gnome with root. I'll test this out in the next days.

If both return the same $HOME on Arch it's fine. On Debian sudo will return /home/User and gksudo /root which causes lots of troubles. That's why I added a clear warning in 1.1.0 to not use sudo.

Revision history for this message
Sparhawk (sparhawkthesecond) said : 		#4

Thanks again for the reply. You are correct. `sudo env | grep ^DBUS` returns nothing.

Huh… I never realised that sudo's env changed between distros. That's really interesing! I had a read of the man page, and found reference to `-E, --preserve-env`. This worked as expected for me. (However, the presence of this option suggests that the default behaviour in Debian is odd?)

Thinking about it again, perhaps my workflow is wrong. Currently I have my backintime config in /root. Most of the time, backintime is triggered by connecting a USB drive, so it probably makes sense to store the config in root's home directory (and use Arch's sudo), since you have physical access to the machine, and are hence already a "superuser".

However, when I manually checksum backup once a month, it probably makes more sense to use the user's home directory, since it's triggered manually at the user level? Perhaps then it would make sense to symlink to root's home, and use `sudo -E`? I'm not sure if this is too convoluted.

Revision history for this message
Germar (germar) said : 		#5

I'm 100% sure, but I think I've read somewhere Debians sudo behaviour is standard but other distros uses 'sudo -i' as default. But nevertheless it's odd!

Don't mix up root and unprivileged users to run on the same config. If you backup your whole machine or files/folders which are not read/writeable by a normal user you should use root all the time.
If you backup your home you should run backintime as your user. You can even do this with Udev. This is an example line which BIT would create in /etc/udev/rules.d/99-backintime-USER.rules:

ACTION=="add", ENV{ID_FS_UUID}=="xxxxxxx-xxxx-xxxx-xxxx", RUN+="/bin/su - 'USER' -c '/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --backup-job >/dev/null 2>&1'"

Revision history for this message
Sparhawk (sparhawkthesecond) said : 		#6

Yes, it probably makes sense to run it all as root then. Thanks for the help!

Revision history for this message
Sparhawk (sparhawkthesecond) said : 		#7

Thanks Germar, that solved my question.