ansible.builtin.debug module – Print statements during execution

Note

This module is part of ansible-core and included in all Ansible installations. In most cases, you can use the short module name debug even without specifying the collections: keyword. However, we recommend you use the FQCN for easy linking to the module documentation and to avoid conflicting with other collections that may have the same module name.

New in version 0.8: of ansible.builtin

Synopsis

  • This module prints statements during execution and can be useful for debugging variables or expressions without necessarily halting the playbook.

  • Useful for debugging together with the ‘when:’ directive.

  • This module is also supported for Windows targets.

Note

This module has a corresponding action plugin.

Parameters

Parameter

Comments

msg

string

The customized message that is printed. If omitted, prints a generic message.

Default: “Hello world!”

var

string

A variable name to debug.

Mutually exclusive with the msg option.

Be aware that this option already runs in Jinja2 context and has an implicit {{ }} wrapping, so you should not be using Jinja2 delimiters unless you are looking for double interpolation.

verbosity

integer

added in 2.1 of ansible.builtin

A number that controls when the debug is run, if you set to 3 it will only run debug when -vvv or above.

Default: 0

Attributes

Attribute

Support

Description

action

Support: full

Indicates this has a corresponding action plugin so some parts of the options can be executed on the controller

async

Support: none

Supports being used with the async keyword

become

Support: none

Is usable alongside become keywords

bypass_host_loop

Support: none

Forces a ‘global’ task that does not execute per host, this bypasses per host templating and serial, throttle and other loop considerations

Conditionals will work as if run_once is being used, variables used will be from the first available host

This action will not work normally outside of lockstep strategies

check_mode

Support: full

Can run in check_mode and return changed status prediction withought modifying target

connection

Support: none

Uses the target’s configured connection information to execute code on it

delegation

Support: partial

Aside from register and/or in combination with delegate_facts, it has little effect.

Can be used in conjunction with delegate_to and related keywords

diff_mode

Support: none

Will return details on what has changed (or possibly needs changing in check_mode), when in diff mode

platform

Platforms: all

Target OS/families that can be operated against

See Also

See also

ansible.builtin.assert

The official documentation on the ansible.builtin.assert module.

ansible.builtin.fail

The official documentation on the ansible.builtin.fail module.

Examples

- name: Print the gateway for each host when defined
  ansible.builtin.debug:
    msg: System {{ inventory_hostname }} has gateway {{ ansible_default_ipv4.gateway }}
  when: ansible_default_ipv4.gateway is defined

- name: Get uptime information
  ansible.builtin.shell: /usr/bin/uptime
  register: result

- name: Print return information from the previous task
  ansible.builtin.debug:
    var: result
    verbosity: 2

- name: Display all variables/facts known for a host
  ansible.builtin.debug:
    var: hostvars[inventory_hostname]
    verbosity: 4

- name: Prints two lines of messages, but only if there is an environment value set
  ansible.builtin.debug:
    msg:
    - "Provisioning based on YOUR_KEY which is: {{ lookup('env', 'YOUR_KEY') }}"
    - "These servers were built using the password of '{{ password_used }}'. Please retain this for later use."

Authors

  • Dag Wieers (@dagwieers)

  • Michael DeHaan