Playbook fails on check but runs fine otherwise

Archives Ansible Project
1

Hi all,

I have a playbook which installs an rpm. The rpm requires input (yikes), so I have written an expect script that is executed. So sadly the yum module is not an option, but it all works fine.

I only want to run the script though, when the rpm is not already present. So I have this:

`

  • name: Check if managesoft is installed
    command: rpm -q managesoft
    ignore_errors: true
    failed_when: rpm_check.rc > 1
    changed_when: false
    register: rpm_check
    when: ansible_os_family == ‘RedHat’
    tags: flexera

  • name: Install expect
    yum:
    name: “expect”
    state: installed
    when: rpm_check.stdout.find(‘is not installed’) != -1 and ansible_os_family == ‘RedHat’
    tags: flexera

`

Now when I run the playbook in check mode like this:

`
ansible-playbook --tags=“flexera” --limit=“x.x.x.x” peganonprd.yml -vC

`

This happens:

`

TASK [flexera : Install expect] ************************************************
fatal: [x.x.x.x]: FAILED! => {“failed”: true, “msg”: “ERROR! The conditional check ‘rpm_check.stdout.find(‘is not installed’) != -1 and ansible_os_family == ‘RedHat’’ failed. The error was: ERROR! error while evaluating conditional (rpm_check.stdout.find(‘is not installed’) != -1 and ansible_os_family == ‘RedHat’): ERROR! ‘dict object’ has no attribute ‘stdout’\n\nThe error appears to have been in ‘/etc/ansible/roles/flexera/tasks/package.yml’: line 11, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Install expect\n ^ here\n”}

`

But if I run it without the -C, it goes through without issues. Which is annoying as I use -C frequently…

How can this be explained?

2

The command module does not run in check mode, it has no way of knowing that the command is safe. The subsequent task depends on that so it fails when the output is skipped.

use always_run: True on the command task to force execution in check mode.

3

Thank you, that was indeed the problem!