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
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
