ufw disable task intermittently fails

[tekenny]

Summary

Performing an ansible run that includes a task to disable ufw when ufw is already disabled ocassionally causes a fatal error regarding another app holding the xtables lock.

Note we've only started getting these failures once we've started using Ubuntu 20.04. Previously we were using Ubuntu 18.04 and this error never occurred on the same systems.

Issue Type

Bug Report

Component Name

ufw module

Ansible Version

ansible 2.9.6
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/tk694h/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0]

Configuration

$ ansible-config dump --only-changed
DEFAULT_TIMEOUT(/etc/ansible/ansible.cfg) = 30
INTERPRETER_PYTHON(/etc/ansible/ansible.cfg) = /usr/bin/python3
RETRY_FILES_ENABLED(/etc/ansible/ansible.cfg) = False

OS / Environment

Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal

Steps to Reproduce

  - name: Ensure UFW is disabled
    ufw:
      state: disabled

Expected Results

I expect that the task to disable ufw to always be succesful (even if ufw is already disabled)

Actual Results

fatal: [sbnod03.test-foxtrot]: FAILED! => {"changed": false, "commands": ["/usr/sbin/ufw status verbose", "/bin/grep -h '^### tuple' /lib/ufw/user.rules /lib/ufw/user6.rules /etc/ufw/user.rules /etc/ufw/user6.rules /var/lib/ufw/user.rules /var/lib/ufw/user6.rules", "/usr/sbin/ufw -f disable"], "msg": "ERROR: problem running ufw-init\nAnother app is currently holding the xtables lock. Perhaps you want to use the -w option?\nAnother app is currently holding the xtables lock. Perhaps you want to use the -w option?\n\n"}

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/system/ufw.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @ahtik @ovcharenko @pyykkis
click here for bot help

[aminvakil]

This is getting checked in ufw integration tests.

community.general/tests/integration/targets/ufw/tasks/tests/basic.yml

Lines 342 to 348 in 2799cd4

	ufw:
	state: disabled
	register: disable
	- name: Disable (idempotency)
	ufw:
	state: disabled
	register: disable_idem

I will see if this is getting run against ubuntu 20.04 or not.

Edit: I don't think this is running in CI, needs to be investigated more.

[aminvakil]

-label needs_triage

[felixfontein]

The ufw tests only run on the RHEL VMs, since they don't work well in docker containers (the Ubuntu tests run in docker containers).

[tekenny]

I'm trying to determine how I can run the ufw integration test via ansible-test on my Ubuntu 20.04 VM to see if I can trouble shoot this intermittent failure but I'm having trouble accomplishing that. I'm viewing https://www.ansible.com/blog/introduction-to-ansible-test but it doesn't state how ansible-test is installed. Does anybody have any suggestions or advise?

[tekenny]

I'd also like to note that the focal-20.04-server-cloudimg-amd64 image was used to create the VM and Python 3.8 is being used, iptables 1.8.4-3ubuntu2 and ufw 0.36-6

[felixfontein]

If you have ansible-core/ansible-base/Ansible 2.9 installed, you already have ansible-test installed.

To run the ufw tests on your machine (which is discouraged, since the tests need root access and modify your machine's state!), you can run ansible-test integration --allow-destructive --allow-root ufw in the community.general checkout (please note that you need to check it out in the correct directory structure to be able to run ansible-test, see for example https://docs.ansible.com/ansible/devel/dev_guide/developing_collections_contributing.html).

[tekenny]

Understood and thanks for the warning I performed the test on a rundant test server.
The test fails with the same error I've intermittently experienced during my ansible playbook runs.

"ERROR: problem running ufw-init\nAnother app is currently holding the xtables lock. Perhaps you want to use the -w option?\n\n"

I've attached the output of the test.

ansible-ufw-test-failure.txt

[aminvakil]

@tekenny It's failing at a different task, right?
At the end of the log you have attached:

TASK [ufw : Enable ufw] **********************************************************************************
changed: [testhost]

TASK [ufw : Make sure logging is off] ********************************************************************
[WARNING]: The value "False" (type bool) was converted to "'False'" (type string). If this does not look
like what you expect, quote the entire value to ensure it does not change.
fatal: [testhost]: FAILED! => {"changed": false, "commands": ["/usr/sbin/ufw status verbose", "/usr/bin/grep -h '^### tuple' /lib/ufw/user.rules /lib/ufw/user6.rules /etc/ufw/user.rules /etc/ufw/user6.rules /var/lib/ufw/user.rules /var/lib/ufw/user6.rules", "/usr/sbin/ufw logging off", "/usr/sbin/ufw status verbose"], "msg": "ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?\n\n\n"}

TASK [ufw : pause] ***************************************************************************************
Pausing for 1 seconds
(ctrl+C then 'C' = continue early, ctrl+C then 'A' = abort)
ok: [testhost]

TASK [ufw : Reset ufw to factory defaults and disable] ***************************************************
fatal: [testhost]: FAILED! => {"changed": false, "commands": ["/usr/sbin/ufw status verbose", "/usr/bin/grep -h '^### tuple' /lib/ufw/user.rules /lib/ufw/user6.rules /etc/ufw/user.rules /etc/ufw/user6.rules /var/lib/ufw/user.rules /var/lib/ufw/user6.rules", "/usr/sbin/ufw -f reset"], "msg": "ERROR: problem running ufw-init\nAnother app is currently holding the xtables lock. Perhaps you want to use the -w option?\n\n"}

It's failing when it's enabled and task is "Reset ufw to factory defaults and disable", not disable when it's disabled, so the problem must be somewhere else.

[tekenny]

Yes it failed upon a ufw disable in my playbook but it appears the integration tests did not get that far and failed before it got to the disable test. I could be wrong but it seems that iptables maybe holding the xtables lock longer in Ubuntu 20.04 than it did in 18.04.

Any suggestions on next steps?

[felixfontein]

It's already failing in Make sure logging is off with Another app is currently holding the xtables lock. The Reset ufw to factory defaults and disable task is a cleanup (and comes after a one-second delay).

That Another app is currently holding the xtables lock appears looks like a bug in ufw and/or iptables and/or Ubuntu 20.04 to me. There is not much we can do. There's a bug report in the ufw repo: https://bugs.launchpad.net/ufw/+bug/1911637

In any case, the module could be better by relying less on "just run the command and see whether something changed", but instead using the same logic as in dry-mode (where it cannot just run commands). I'm not sure whether it would help with this specific bug, but it definitely does not hurt to do that.

[tekenny]

I agree this looks like the failure is due to a ufw bug unrelated to ansible. Thank you very much for all the assistance!