On Fri, Jan 31, 2014 at 11:25 AM, Andrew Dunstan <[email protected]> wrote: > > > Greetings, > > we have a customer who reports difficulties fetching a backup as shown > below. > > The platform is wal-e 0.6.6 on Python 2.7 on Ubuntu 11.04, linux kernel > 2.6.38-16-virtual on x86_64. > > Does anyone have any clue what might be going on here?
What's the size of the parent process? My guess is fork() is dying to start lzop on account of a large footprint in WAL-E. I've never seen such a file descriptor exhaustion on the fetch-side before...only a related problem with retries and bugs in subprocess on the push-side, not present in this version in any case. Is the backup returning an abnormal exit code, e.g. "1"? Are there any stack traces in the backup-fetch logs? Are there backup-fetch logs? What versions are the backups being taken on? Same? I ask because some of the segmentation routines have been changed to make things a bit easier on memory. Can the test be reproduced in similar style with the contents of the branch "v0.6" in git, including this patch in particular? https://github.com/wal-e/wal-e/commit/a38233a756d0e6bb45f9819bb98f1b56039c8c75 -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
