ansible
ansible copied to clipboard
ansible
unarchive gives error "Failed to find handler" when the handler is present, but the dest location is non-existent.
SUMMARY
I was mistakenly testing with a dest value that was a relative path. When the [g]tar commands all failed because the dest directory did not exist I got the "Failed to find handler" error. This probably could be better handled by checking that the dest directory existed before calling tar.
ISSUE TYPE
- Bug Report
COMPONENT NAME
unarchive
ANSIBLE VERSION
ansible 2.8.4
config file = /cygdrive/c/Users/WayneJohnson/PhpstormProjects/hl7connector/ansible.cfg
configured module search path = ['/home/WayneJohnson/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.7/site-packages/ansible
executable location = /usr/bin/ansible
python version = 3.7.7 (default, Apr 10 2020, 07:59:19) [GCC 9.3.0]
CONFIGURATION
ANSIBLE_PIPELINING(/cygdrive/c/Users/WayneJohnson/PhpstormProjects/hl7connector/ansible.cfg) = True
DEFAULT_HOST_LIST(/cygdrive/c/Users/WayneJohnson/PhpstormProjects/hl7connector/ansible.cfg) = ['/cygdrive/c/Users/Wayne>
HOST_KEY_CHECKING(/cygdrive/c/Users/WayneJohnson/PhpstormProjects/hl7connector/ansible.cfg) = False
OS / ENVIRONMENT
Windows 10 with Cygwin
STEPS TO REPRODUCE
unarchive task with relative (and non-existent) path
- name: unarchive tarball
unarchive:
src: dcmtk-3.6.5.tar.gz
dest: "dcmtkBuild"
register: archive
EXPECTED RESULTS
Error that explains that I don't know what I am doing and the dest directory is an absolute path and it should exist.
ACTUAL RESULTS
You don't know what you are doing. The dest directory is an absolute path and should exist.
Files identified in the description:
If these files are incorrect, please update the component name section of the description or use the !component bot command.
Can you provide a full reproducer for this issue, including full output with -vvv?
needs_info
This is not a duplicate (AFAIK) to #46780. In my case there is no delegate_to:
Attached, please find a playbook and log of the error Issue72492.zip The source file used in this test (just about any .tar.bz file will do) is https://dicom.offis.de/download/dcmtk/dcmtk365/dcmtk-3.6.5.tar.gz
BTW, I do have unzip and gtar installed.
I did some experiments with unarchive.py. It looks like the gtar fails due to the missing directory (dcmtkBuild) and returns an RC, but the code mistakes the reason as missing unzip (or bzip2 in this case).
I spent quite a bit of time debugging this because of the misleading error.
Thanks for looking at this.
I believe delegate_to is unrelated to the actual bug in #46780, but you may be right that it isn't a duplicate. I didn't dig too much into it, but it looks very similar.
Why must the destination be absolute, by the way? Is not it a given, that everything is relative to the ansible_ssh_user's home directory?
Oh, it is even worse -- as I just discovered, the source needs to be absolute too for some inexplicable reason.
And, on top of it, when claiming that the "handler failed", the module would not give the actual error output by gtar or unzip -- a separate bug of its own.
Here is my "reproducer":
- name: Download {{ phpbb.url }}
get_url:
dest: .
sha256sum: '{{ phpbb.sha256 }}'
url: '{{ phpbb.url }}'
register: phpbb_download
- debug: var=phpbb_download
- name: Create {{ phpbbdir }}
file:
path: '{{ phpbbdir }}'
state: directory
mode: '0755'
- name: Extract {{ phpbb_download.dest }} into {{ phpbbdir }}
unarchive:
src: '{{ phpbb_download.dest }}'
remote_src: True
dest: '{{ phpbbdir }}'
extra_opts:
- --strip-components=1
The first task -- the download -- works perfectly fine with the relative destination. But, when I attempt to use that destination later for extraction, I get the same error as the topic-starter. Attaching the verbose output...
The workaround is to replace the download's destiation with '{{ ansible_user_dir }}'. It should not be necessary.
And any failures of the "handlers" should be quoted verbatim. bug.txt
Very frustrating bug. Took me hours to figure out what was going on. Could not the module simply check whether the destination exists before trying to extract it?
Actually, it looks like this is checked, at least in the latest version. Unfortunately, we haven't migrated from RHEL 7 yet, and installing via pip is not so simple.
In my case, the problem was that the dest was incorrectly specified as relative, but my version of unarchive apparently doesn't support that. In the latest version it converts the path to absolute first, which should have worked. Though it would have extracted the archive to the wrong place. But that's user error.
I do wish Redhat would have patched this, rather than kicking it forward to a later major release.
Seems like this issue should be closed, though.
I am not able to reproduce this issue in the latest Ansible version. Could you please check with latest version and let us know? Thanks,
@wdtj This Issue is waiting for your response. Please respond or the Issue will be closed.
@wdtj You have not responded to information requests in this Issue so we will assume it no longer affects you. If you are still interested in this, please create a new Issue with the requested information.