Re: [rdiff-backup-users] locking the rdiff-backup destination

[Jakob Unterwurzacher]

Am 2009-12-24 06:50, schrieb Alex Samad:
>>
> > I guess you will have to use a wrapper script for your rsync job and
> > your rdiff-backup job that does the locking (and obeys the lock).
>
> yep doing something like that already, but I noticed that rdiff-backup
> has a way of knowing when another riff-backup is running against the
> dest, it would be could to be able to trigger that flag as well from
> outside rdiff-backup

Indeed. I had not noticed that.

This is what rdiff-backup does (strace) when there is another instance 
running:

> $ strace rdiff-backup /usr/sbin /tmp/des
[...]
> open("/tmp/des/rdiff-backup-data/current_mirror.2009-12-24T10:50:52+01:00.data",
>  O_RDONLY|O_LARGEFILE) = 4
[...]
> read(4, "PID 9157\n", 4096)             = 9
[...]
> kill(9157, SIG_0)                       = 0
> write(2, "Fatal Error: It appears that a p"..., 298
> Fatal Error: It appears that a previous rdiff-backup session with process
> id 9157 is still running.  If two different rdiff-backup processes write
> the same repository simultaneously, data corruption will probably
> result.  To proceed with regress anyway, rerun rdiff-backup with the
> --force option.
> ) = 298

So, when you read out the PIDs from the
rdiff-backup-data/current_mirror.*
files (they contain "PID 12345"), check whether one of them is running, 
and none is, then it's safe to start rsync.

Note that
$ kill -0 PID
is somewhat unsafe as a check whether PID is running. It will return 1 
when the process does not exist but will also return 1 when the process 
exists but you don't have the permission to send a signal to it. I'd use 
ps -p.


Jakob