On 01/31/2014 02:42 PM, Daniel Farina wrote:
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.
The archiving version is 0.6.5. Do we need to upgrade? Before we
recommend that I'd like to make darn sure that it will then work.
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
Yes, we can test that.
I'll get answers to the other questions.
cheers
andrew
--
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.
