Remote script failed to execute properly
Closed this issue · 4 comments
CentOS 7:
lvcreate -L 1M -n bscp-test staticnode13
lvcreate -L 2M -n bscp-test2 staticnode13
/tmp/bscp /dev/staticnode13/bscp-test localhost:/dev/staticnode13/bscp-test2 4194304 sha1
results in:
Traceback (most recent call last): File "/tmp/bscp", line 176, in <module> (in_total, out_total, size) = bscp(local_filename, remote_host, remote_filename, blocksize, hashname) File "/tmp/bscp", line 132, in bscp raise RuntimeError('Remote script failed to execute properly') RuntimeError: Remote script failed to execute properly
While it does not make any difference, if you use LVM backed or ZFS backed or File backed raw devices as well if you talk to the sshd via localhost or external.
What exactly does this mean "Remote script failed to execute properly" ?
I understand that its coming from
sanity_digest = hashlib.new(hashname, remote_filename).digest() remote_digest = io.read(len(sanity_digest)) if remote_digest != sanity_digest: raise RuntimeError('Remote script failed to execute properly')
But i have no idea why :-)
@vog This issue might be because of the two file names being different. The error message is a bit ambiguous and I think the hash of the filenames simply results in different hashes values.
Picking up traceback and error messages from the remote script would probably help debugging cases like this.
There might also be some concerns about sending bytes data across a piped SSH python interpreter shell. The remote script might fail also because of byte encoding being different on two machines and the terminals reacting on the piped data. Encoding of the data some how before transfer and decode it on the other end would help avoid this kind of issue, for instance base64 or a pre-determined encoding (mainly between operating systems as well as terminals. I'm pretty sure the SSH session spawns the Python interpreter in the default shell/tty of that user, and it might pick up on certain bytes being printed/sent to the tty).
The file size difference is only verified one way, if the source is smaller than the target (I've only quickly looked at the code so I might be wrong here). Which potentially might cause hash checks to raise errors if verified on both entire files. Truncating the file is only done if the file doesn't exist and should perhaps be done on the entire file (as a parameter?).
I'd like to push a PR for this, but this fix would probably mess up a lot of the original structure and deviate from the original setup of pushing a remote script. And I apologies if I sounded harsh in my previous edit of this response.
Side notes:
Other file-meta's are not preserved either it seams, such as modified time for instance. Not that it's a vital part of data integrity, but might be useful.
The processes p.stdout is not closed either, leaving file handles in a open/pending state for longer than needed. I don't think p.wait() actually closes these, just waits for the process to exits. Running this script to many times in succession might cause IO opens to fail.
Sorry for not being very responsive here. Please see #16 "Future of bscp" for more information.
As a quick note, the reason for allowing for non-complete overwriting of the target is:
The target "file" might be a block device that happens to be larger than the source image. See #1 and #4. In that case the backup should still succeed, and if it is e.g. the (possibly encrypted) image of a virtual machine, it would run on that larger device on the new machine as well. It may be, however, that this special case is no longer in use and thus did not receive enough testing in the past.
I believe this is fixed by now. Moreover, the script output has been improved to show remote error messages in addition to local error messages, to ease debugging. Also, many improvements in this area happened during the transition to Python 3.
I'm closing this for now, but please feel free to reopen this ticket (or open a new one) if this error message appears again.
output has been improved to show remote error messages
Great work! And thank you for that improvement. Should help debugging, especially for new users.