| 2015-03-19 12:09:27 |
Kenneth Loafman |
description |
We've got some automation built up around duplicity, but we're having some occasional trouble with duplicity exiting with code -1 during a restore. eg:
Writing foo/bar.jpg of type reg
Deleting /var/lib/tmp/duplicity-GYz7n0-tempdir/mktemp-yHEK5p-7
Processed volume 6 of 49
Ended with non-successful exit code (-1)
With the last line of output originating from our system.
I've looked at the pydoc for the ErrorCode class, and it explicitly states that negative return codes are not to be used. The best I've been able to turn up is that Python subprocesses will return a negative status reflecting the signal they were sent, -1 correlating to SIGHUP.
Investigating this further I've found that duplicity.pexpect.run() appears to be calling the close() function on child processes which issues a SIGHUP, and then returning the child's status.
Is this an expected behaviour? Can we safely assume that a -1 exit status is OK from duplicity?
This is pure inference, but is duplicity issuing an early close() on the subprocess handling the restore once it has restored the necessary files, and then the -1 return code gets passed up through the stack until duplicity exits? |
From: https://answers.launchpad.net/duplicity/+question/262087
We've got some automation built up around duplicity, but we're having some occasional trouble with duplicity exiting with code -1 during a restore. eg:
Writing foo/bar.jpg of type reg
Deleting /var/lib/tmp/duplicity-GYz7n0-tempdir/mktemp-yHEK5p-7
Processed volume 6 of 49
Ended with non-successful exit code (-1)
With the last line of output originating from our system.
I've looked at the pydoc for the ErrorCode class, and it explicitly states that negative return codes are not to be used. The best I've been able to turn up is that Python subprocesses will return a negative status reflecting the signal they were sent, -1 correlating to SIGHUP.
Investigating this further I've found that duplicity.pexpect.run() appears to be calling the close() function on child processes which issues a SIGHUP, and then returning the child's status.
Is this an expected behaviour? Can we safely assume that a -1 exit status is OK from duplicity?
This is pure inference, but is duplicity issuing an early close() on the subprocess handling the restore once it has restored the necessary files, and then the -1 return code gets passed up through the stack until duplicity exits? |
|
