Thanks. The previous message actually wasn't mine and I don't know if the problem I found had anything to do with his issue. In any event, I will try your suggestions if the problem recurs. For now --exclude is fine since I don't need that directory backed up anyway. The directory (or directories, one for each chrooted user) in question does mount some stuff in /proc so you're probably correct in your diagnosis.
drwxr-xr-x 2 root root 2048 Jun 28 23:39 bin
-rwxr-xr-x 1 root root 1320 Aug 2 21:36 checkvirtfs
drwxr-xr-x 4 root root 2048 Jul 15 04:35 dev
drwxr-xr-x 4 root root 2048 Jul 27 20:27 etc
drwxr-xr-x 3 root root 2048 Jul 27 20:27 home
drwxr-xr-x 10 root root 6144 Jun 28 23:39 lib
drwxr-xr-x 2 root root 2048 Feb 21 2005 opt
dr-xr-xr-x 2860 root root 0 Jul 15 04:34 proc
drwxrwxrwt 3 root root 6144 Aug 3 12:42 tmp
drwxr-xr-x 12 root root 2048 Jul 27 20:27 usr
drwxr-xr-x 7 root root 2048 Jul 27 20:27 var
rac
Message: 4
Date: Sun, 3 Aug 2008 10:08:28 +0200
From: Peter Schuller <address@hidden>
Subject: Re: [Duplicity-talk] IOError: [Errno 3] No such process
To: Discussion of the backup program duplicity
<address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
> 338, in read
> buf = self.infile.read(length)
> IOError: [Errno 3] No such process
>
> In my case, on a cPanel VPS running on CentOS 4.6, the cause appears to be
> attempting to backup the /home/virtfs/ directory. This is where cPanel sets
> up chroot jails for shell users. I guess it's a permissions problem. But
> fixing it was as simple as adding --exclude=/home/virtfs to the Duplicity
> command.
It seems it gets the 'no such process' on *reading*, which indicates
it should be a separate problem from gpg dying (as talked about in
your original post).
I suspect, since you say these are chroots, that duplicity is simply
backing up some particular special file which as special semantics
when read from (let's say it traverses the chroot's mounted /proc file
system or something along those lines).
I don't know specifically which file might be most likely to be the
actual problem here though. if you wish to find out more, I suggest
re-running, without the --exclude, with -v9 (or even just -v5 should
be enough) to see which file duplicity is backing up at the time it
fails.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.gnu.org/pipermail/duplicity-talk/attachments/20080803/433dd526/attachment.bin
------------------------------
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk