[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jakob Unterwurzacher
Subject: Re: [rdiff-backup-users] locking the rdiff-backup destination
Date: Thu, 24 Dec 2009 11:30:35 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20091204 Thunderbird/3.0

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
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
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]