Virtualmin backup failed with lockfile error: Failed to lock file /home/someuser/.backup

4 posts / 0 new
Topic locked
Last post
#1 Sat, 07/13/2013 - 22:02
dly

Virtualmin backup failed with lockfile error: Failed to lock file /home/someuser/.backup

Our housing provider's network went down causing a scheduled backup to fail. Weirdly, it was still running two days later, so I killed it. But it somehow kept an annoying lockfile around.

A manual backup ended with the error:

Backup failed : Failed to lock file /home/someuser/.backup after 5 minutes. Last error was :

How should I fix this lock file? Should I just delete the .backup directory?

Sat, 07/13/2013 - 22:06
andreychek

Howdy,

You shouldn't need the .backup directory... but also, what output does this command produce:

ls -la /home/someuser/*.lock

I'm curious if there's any lock files remaining in that home directory.

-Eric

Sat, 07/13/2013 - 22:33
dly

The output is:

[root@hostname ~]# ls -la /home/sucadmin/*.lock
ls: cannot access /home/someuser/*.lock: No such file or directory

But check this out:

[root@web4 sucadmin]# ls -la *.lock
ls: cannot access *.lock: No such file or directory
[root@web4 sucadmin]# ls -la .*.lock
-rw-r--r-- 1 root root 6 Jul 10 00:07 .backup.lock

Since it's a hidden file. I have to add a . at the beginning to see it show up. Not sure why, but it seems to be true.

Perhaps there is a bug with the .backup.lock's behavior? Maybe Virtualmin's backup program is *only* checking for the existence of the .backup.lock file? (With perl's -e file test, for example.)

If that *is* the case, then you should look into using Perl's (actually Linux's, actually Unix's) flock feature. Where you do not base if a lockfile is locked by its mere presence (-e file test); instead, in the program that wants to lock the file. First you open and create it if needed, and then you lock it using flock() (See: http://perldoc.perl.org/functions/flock.html) For example:

flock $fh, LOCK_EX | LOCK_NB or die "Failed to get lockfile: $lockfile";

Then if flock succeeds, you successfully locked the lockfile, and can proceed, but if the flock fails, then you should not proceed, and print an error message, or do whatever else is appropriate.

The benefits of using flock is you not longer must delete the lock file when your program successfully suceeds. Instead, the OS unlocks the file for you when your program exits, but it still exists. (So, all tests if the lock is really locked, must also be replaced with flock attempts.)

The only downside, is if this behavior is not a bug. That is if the backup fails for some reason, that you do indeed want the lockfile around to indicate that the backup is stuck half way, and perhaps needs some user intervention. But if just deleting the lockfile (.backup.lock) and the .backup directory is enough for the next backup to succeed, then flock should probably be used.

Thanks,
Dave.

Wed, 07/17/2013 - 02:11
dly

I deleted the .backup.lock file and the .backup directory, and now it works great.

Thanks, Dave.

Topic locked