Unarchive task fails second time it's ran

[sebastiaopf]

ISSUE TYPE

• Bug Report

COMPONENT NAME

unarchive

ANSIBLE VERSION

ansible 2.3.0.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

OS / ENVIRONMENT

Controller site: 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Host: 4.4.0-1013-aws #22-Ubuntu SMP Fri Mar 31 15:41:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

SUMMARY

Unarchive module fails with "Error: a bytes-like object is required, not 'str'\r\n" error message, but only if the task would not be executed, because the files are already extracted on the remote host.

STEPS TO REPRODUCE

• Create a task that uses unarchive to extract some files to the remote host
• Run the task for the first time, when the files don't exist on the remote host
• Task should complete without errors
• Run the task again, without changing anything
• Task should fail with "Error: a bytes-like object is required, not 'str'\r\n"" error message

Python version on remote host is Python 3.5.2.

Full error message:

fatal: [***]: FAILED! => {"changed": false, "failed": true, "module_stderr": "Shared connection to *** closed.\r\n", "module_stdout": "\r\nTraceback (most recent call last):\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 885, in <module>\r\n    main()\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 839, in main\r\n    check_results = handler.is_unarchived()\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 475, in is_unarchived\r\n    crc = crc32(dest)\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 172, in crc32\r\n    return binascii.crc32(open(path).read()) & 0xffffffff\r\nTypeError: a bytes-like object is required, not 'str'\r\n", "msg": "MODULE FAILURE", "rc": 0}
	to retry, use: --limit @...

- name: Extract application files to server
  unarchive:
    src: roles/myapp/files/app.zip
    dest: /opt/myapp
    creates: README.md

EXPECTED RESULTS

Task should execute without errors both times.

ACTUAL RESULTS

Task fails the second time it's executed (when files already exist on the server)

Removed host name but it's ec2 instance.

fatal: [***]: FAILED! => {"changed": false, "failed": true, "module_stderr": "Shared connection to *** closed.\r\n", "module_stdout": "\r\nTraceback (most recent call last):\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 885, in <module>\r\n    main()\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 839, in main\r\n    check_results = handler.is_unarchived()\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 475, in is_unarchived\r\n    crc = crc32(dest)\r\n  File \"/tmp/ansible_i9aq7ts5/ansible_module_unarchive.py\", line 172, in crc32\r\n    return binascii.crc32(open(path).read()) & 0xffffffff\r\nTypeError: a bytes-like object is required, not 'str'\r\n", "msg": "MODULE FAILURE", "rc": 0}
	to retry, use: --limit @...

[ansibot]

cc @dagwieers @pileofrogs
click here for bot help

[sebastiaopf]

Complementing, this could be somewhat related to #17038 and as per @abadger comment (#17038 (comment)) i'm opening a new issue.

[nitzmahone]

Does it fail the same way under Python2?

[sebastiaopf]

Didn't try with python 2, since this remote host only has python 3 installed. Will spin up a Vagrant vm and test with that.

[sebastiaopf]

@nitzmahone didn't happen for me with python2 on the remote host.
Do you need any other test performed?

[ghost]

Hi. Today I had a similar issue. After second run of unarchive task with "list_files=True" I can't ssh into servers anymore with my deploy user. The ownership for /home/$USER is changed to the user with UID 1000. In my case from ansible:users into ubuntu:users and centos:users for centos machines.

[abadger]

Fixed for devel in: c7860d4 and cherry-picked to the stable-2.3 branch here: 561d424

This should be fixed when 2.3.1.is released.

[sebastiaopf]

@abadger Thank you very much for the quick fix.