Udev rule overwritten when drive is not attached (was: Backup fails if triggered via udev rules)

[bovender]

Hi,

I've noticed that backups fail if they are triggered via udev rules.

I have configured BiT to backup to an external harddrive (Ext4) whenever it is plugged in. The backup starts and proceeds until permissions are saved. However, the backup never appears in the list of snapshots. The log ends with saving file permissions. No error is being logged.

When I trigger the backup manually, it works just fine with that drive.

[Germar]

Please run sudo nano /etc/udev/rules.d/99-backintime-$(whoami).rules and replace >/dev/null at the end with

--debug 2>&1 >/tmp/bitudev.log

do not start BiT again because it would overwrite the rule. Just plug in your drive, let it create a new snapshot and post the output of /tmp/bitudev.log

[bovender]

Thanks for your feedback. I did some experimenting and it's getting complicated.

First, adding the logging to the udev rule produces errors in the syslog:

systemd-udevd[17367]: Process '/bin/su - 'daniel' -c '/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --profile-id 2 backup-job --debug 2>&1 >/tmp/bitudev.log'' failed with exit code 1.

Don't know exactly what is causing the exit code 1; su returns 1 on authentication failure which can be ruled out (I guess) because the udev rule is executed by root.

When I change the udev rule back to >/dev/null as before, I now get this (timestamps removed by me):

 backintime (daniel/2): INFO: Lock
 backintime (daniel/2): INFO: Take a new snapshot. Profile: 2 Complete
 backintime (daniel/2): ERROR: /media/daniel/DanielComplete/backintime/seppel5/daniel/2 does not exist
 kernel: [43318.007958] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)
 udisksd[2125]: Mounted /dev/sdc1 at /media/daniel/DanielComplete on behalf of uid 1000
 backintime (daniel/2): INFO: Remove leftover 'new_snapshot' folder from last run

BackInTime attempts to access the backup folder before it is actually mounted. This is issue #605 (I had made a duplicate report of this in #674) and it was fixed already.

$ backintime -v
backintime 1.2.0~alpha16

(That's from the testing ppa.)

So that's puzzling me right now, especially since I used to have the behavior described in my first post until I started my investigations.

[buhtz]

@bovender There is a new forming maintaining team and we do review all issues. Is this problem still relevant for you or did you find a solution?

Tags: Feedback, udev

[bovender]

Thanks for your feedback. In the past years, I have simply triggered the backup manually. Tried it again now with the udev rule, and it still seems (as per the syslog) that BiT attempts to start the backup as soon as the drive is connected, but unfortunately before the file system is actually mounted.

It's not a big deal really. Just a nice luxury feature that's not working for me ;-)

Great to hear that the project is being revived! :-) I use Back In Time all the time...

My machine currently runs on KDE neon:

Operating System: KDE neon 5.25
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.15.0-48-generic (64-bit)
Graphics Platform: X11

[bovender]

I was able to investigate further. Apparently there are two problems:

1. The udev rules are written incorrectly when BiT starts while the drive is not attached.
2. Once the backup is triggered by a udev rule, it immediately stops as in 2017, but the log is different.

---

Here's an excerpt of the output of lsblk with my external drive attached (irrelevant lines removed from output):

NAME        FSTYPE   FSVER LABEL            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sdb
└─sdb1      ext4     1.0   COMPLETE_2022_12 09bbe12b-836b-4740-ac13-7480728b61ee      1T    39% /media/daniel/COMPLETE_2022_12
nvme0n1
├─nvme0n1p3 ext4     1.0                    41fade75-c6f4-4989-9a90-0a8cf2585c76   96,2G    15% /

• The external drive's UUID starts with 09bbe.
• The root partition on the built-in harddrive has a UUID that starts with 41fad.

Here's the udev rule when I configure BiT to create a backup when the drive is plugged in:

daniel@seppel7:/etc/udev/rules.d$ cat 99-backintime-daniel.rules
ACTION=="add|change", ENV{ID_FS_UUID}=="09bbe12b-836b-4740-ac13-7480728b61ee", RUN+="/usr/bin/su - 'daniel' -c '/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --profile-id 3 backup-job >/dev/null'"

When I disconnect the drive and some time later start BiT without the external drive attached, the rules are being overwritten:

daniel@seppel7:/etc/udev/rules.d$ cat 99-backintime-daniel.rules
ACTION=="add|change", ENV{ID_FS_UUID}=="41fade75-c6f4-4989-9a90-0a8cf2585c76", RUN+="/usr/bin/su - 'daniel' -c '/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime --profile-id 3 backup-job >/dev/null'"

As you can see, the rule with UUID 09bbe was overwritten with the exact same rule, but with UUID 41fad. As a result, when I now plug in the external drive, no rule will be triggered.

It only works if I never, ever start BiT without the external drive attached. Then, the udev rule contains the appropriate UUID, and when I plug in the drive, the rule is being triggerd.

---

kernel: [59790.264227] scsi 1:0:0:0: Direct-Access     WD       Elements 2621    1034 PQ: 0 ANSI: 6
kernel: [59790.265044] sd 1:0:0:0: Attached scsi generic sg1 type 0
kernel: [59790.266857] sd 1:0:0:0: [sdb] Spinning up disk...
kernel: [59791.286669] ....ready
# ... noise removed ...
udisksd[1358]: Mounted /dev/sdb1 at /media/daniel/COMPLETE_2022_12 on behalf of uid 1000
kernel: [59795.742425] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none.
systemd[1]: Started Session c11 of User daniel.
backintime (daniel/3): INFO: Lock

Surprisingly, and this is different from 2017, there is absolutely no further output from BiT in the log. "INFO: lock" is all it says. Just nothing happens. Odd.

[buhtz]

Thank you very much for your analysis. This helps a lot.
Quick n dirty summary: The udev rule is overwritten when the drive is not attached.