Missing support for multiple users on the same host / same lock-file used by user and root

[mat-m]

Hello

I had an issue where snapshots were not taken.
I decided to run in CLI with /usr/bin/backintime backup --debug and got:

DEBUG: [common/snapshots.py:1751 Snapshots.flockExclusive] Set flock /tmp/backintime.lock
Traceback (most recent call last):
  File "/usr/share/backintime/common/backintime.py", line 1165, in <module>
    startApp()
  File "/usr/share/backintime/common/backintime.py", line 517, in startApp
    args.func(args)
  File "/usr/share/backintime/common/backintime.py", line 739, in backup
    ret = takeSnapshot(cfg, force)
  File "/usr/share/backintime/common/backintime.py", line 94, in takeSnapshot
    ret = snapshots.Snapshots(cfg).backup(force)
  File "/usr/share/backintime/common/snapshots.py", line 633, in backup
    self.flockExclusive()
  File "/usr/share/backintime/common/snapshots.py", line 1752, in flockExclusive
    self.flock = open(self.GLOBAL_FLOCK, 'w')
PermissionError: [Errno 13] Permission denied: '/tmp/backintime.lock'

Actually, the lock belongs to the other user, which also has a @reboot job, but starts before me.

Flock should hold user & BIT profile name, IMO.

[buhtz]

Can you provide an ls -l for /tmp/backintime.lock please.

[mat-m]

Current one for me:

➜ ls -l  /tmp/backintime.lock 
-rw-rw-rw- 1 mm mm 0 déc.  20 01:35 /tmp/backintime.lock

[gitraphha]

Hello,
this behaviour occurs on my machine as well, so I'd like to contribute some details of what happens when in my case.

BIT version: 1.2.1 (running on Kubuntu 21.04)

If a regular user "reguser" runs a backup job (or their job is automatically started by cron), the following lock file is created when the backup job starts (i.e. not already at (manual) program startup).

ls -l /tmp/backintime*
-rw-rw-rw- 1 reguser reguser 0 Sep  1 16:11 /tmp/backintime.lock

The problem then is - this lock file is not deleted on completion of the backup job.

So if some time later root runs a backup job (again possibly their job is automatically started by cron, same behaviour) it will fail and I get the above mentioned error:
PermissionError: [Errno 13] Permission denied: '/tmp/backintime.lock'
If I manually delete this file, root's or my reguser's backup job (manual or started by cron) runs without problems.

So this seems to be exactly this problematic multi-user setting. For me it would be fine if the second user can't start their job before the first user's job is finished (as selected under "settings-options-run only one snapshot at a time", which is activated in my case for both reguser and root). However, if this first job is finished, the lock file should be removed, shouldn't it?

Thanks for looking into this...
Raph

[gitraphha]

some more information about starting and running backups as reguser and root, details see attached file
backintime_steps.log

tl;dr:

• reguser can run backups after root ran theirs (backintime.lock persists all the time and is owned by root)
• root can NOT run backups after reguser ran theirs (backintime.lock persists all the time and is owned by reguser)

[buhtz]

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?

@gitraphha Thanks for your summary about the problem.

Tag: Feedback, Bug, Scheduling, Medium

[mat-m]

@buhtzz Glad a new team is coming ! Thanks so much for this !
I worked it around by using root everywhere (not ideal, though). Also, maybe the lock name is too generic to handle mutli-users or multi-targets. I actually don't know what you want to lock. In my opinion, the lock should be on the target dir.

[emtiu]

Okay, so the cause of the bug seems to be that in certain situations, /tmp/backintime.lock is not deleted for some reason.

More generally, it's worth a look at why that logfile exists in the first place, and if it could be changed to a per-user lock.

[fallingrock]

I'm seeing the same thing.

I've got two backup's scheduled ... one for my home directory that runs hourly (running as me), and one for the entire system (running as root).

The root backup frequently doesn't run because that lock file exists owned by my own profile.