> On Sun, Oct 7, 2012 at 2:03 AM, Laurynas Biveinis <
>
address@hidden> wrote:
>
>> <SNIP>
>> OK it took a while, but here it is.
>>
>> The script I used
>>
>> duplicity -v9 -t19D --file-to-restore file &
>> duplicity_pid=$!
>> lsof -p $duplicity_pid +r 300 &
>>
>> while ps aux | grep [d]uplicity >/dev/null 2>&1
>> do
>> date
>> ls -lAR $TMP
>> du -c $TMP
>> df -h --sync $TMP
>> sleep 300s
>> done
>>
>
> Jumping in here. I went back through the messages and I would like for you
> to check some things, please...
>
> - In /usr/lib/python2.x/dist-packages/duplicity there should be files named
> GnuPGInterface.py and .pyc. If you examine GnuPGInterface.py around line
> 660 there should be a function called threaded_waitpid.
>
> - In the same library, there should be a file called gpg.py containing
> 'from duplicity import GnuPGInterface' near line 30.
>
> The reason I ask this is that it does look like the gpg resource problem is
> biting you, and here's how. In Linux it it possible to create a file,
> delete it, and write to it. The file will be accessible to the program
> until it is closed. If you don't have the above code, the file may not be
> closed, and the resources may not be freed.
>
> If that is the case, download both files directly from the release code at
>
http://bazaar.launchpad.net/~duplicity-team/duplicity/0.6-series/files/head:/duplicity/.
> There is a green arrow at the far right for download. Copy these over the
> old files and remove their .pyc files for safety. If you go back through
> the process again, you will see 2-3 gpg processes at a time, but not a long
> list.
>
> Let us know how it goes, and thanks go to you and edso for hanging in
> there. We'll get this fixed.
>