Bug 1379141 - Fail2ban prevents restarting firewalld
Summary: Fail2ban prevents restarting firewalld
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fail2ban
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1317240
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-25 11:58 UTC by kakoskin
Modified: 2016-10-09 06:20 UTC (History)
7 users (show)

Fixed In Version: fail2ban-0.9.5-3.fc24
Clone Of:
Environment:
Last Closed: 2016-10-09 06:20:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
journalctl -u firewalld -u fail2ban for failure and subsequent restart with fail2ban stopped. (1.28 KB, text/x-vhdl)
2016-09-25 11:58 UTC, kakoskin
no flags Details
journalctl -PID=1 for failed restart and following restart with fail2ban stopped. (3.41 KB, text/x-vhdl)
2016-09-25 12:00 UTC, kakoskin
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1317240 0 unspecified CLOSED RFE: add firewall.target 2021-02-22 00:41:40 UTC

Internal Links: 1317240 1573185

Description kakoskin 2016-09-25 11:58:21 UTC
Created attachment 1204531 [details]
journalctl -u firewalld -u fail2ban for failure and subsequent restart with fail2ban stopped.

Description of problem:
Running fail2ban service prevents restarting firewalld. I have to resort to stopping and starting firewalld separately. After stopping fail2ban firewalld restart works as expected. 

Version-Release number of selected component (if applicable):
firewalld-0.4.3.3-1.fc24.noarch
fail2ban-0.9.4-5.fc24.noarch
systemd-229-13.fc24.x86_64

How reproducible:


Steps to Reproduce:
1. Install and start fail2ban.
2. systemctl restart firewalld

Actual results:
[huginn@beowulf ~]$ sudo systemctl restart firewalld
Failed to restart firewalld.service: Transaction contains conflicting jobs 'restart' and 'stop' for fail2ban.service. Probably contradicting requirement dependencies configured.
See system logs and 'systemctl status firewalld.service' for details.


Expected results:
Firewalld is restarted without errors. 

Additional info: 
Both sequences:
1. systemctl stop fail2ban
2. systemctl restart firewalld
2. systemctl start fail2ban

or 

1. systemctl stop firewalld
2. systemctl start firewalld

work as expected.

Comment 1 kakoskin 2016-09-25 12:00:12 UTC
Created attachment 1204532 [details]
journalctl -PID=1 for failed restart and following restart with fail2ban stopped.

Comment 2 Michael Chapman 2016-09-26 10:25:04 UTC
I can confirm this bug. It's unclear what's caused it, as I haven't touched any of these packages on my system for about a month.

Comment 3 Vedran Miletić 2016-10-01 11:13:59 UTC
Can confirm as well.

Comment 4 Michael Chapman 2016-10-01 13:49:32 UTC
The problem appears to be because fail2ban.service is part of *both* firewalld.service and iptables.service:

  # /usr/lib/systemd/system/fail2ban.service
  [Unit]
  ...
  PartOf=firewalld.service iptables.service

and because firewalld.service explicitly conflicts with iptables.service:

  # /usr/lib/systemd/system/firewalld.service
  [Unit]
  ...
  Conflicts=iptables.service ip6tables.service ebtables.service ipset.service

So when you restart firewalld.service:

- the restart is propagated to fail2ban.service, since fail2ban.service is part of firewalld.service;
- a stop job is prepared for iptables.service, since iptables.service is conflicted by firewalld.service;
- the stop job on iptables.service is propagated to fail2ban.service, since fail2ban.service is part of iptables.service;
- systemd detects that fail2ban.service has both a restart job and a stop job, and these jobs can not be merged.

This problem appears to be raised on systemd's issue tracker already:

  https://github.com/systemd/systemd/issues/2830

Perhaps systemd should not propagate a stop job through an already-stopped unit? That way, since iptables.service is currently stopped (in fact, it doesn't even exist on my system), then that stop action wouldn't propagate to fail2ban.service too.

Comment 5 Fedora Update System 2016-10-05 02:26:04 UTC
fail2ban-0.9.5-3.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-7db83f651b

Comment 6 Vedran Miletić 2016-10-05 09:57:41 UTC
Seems to fix the issue. Though I still get firewalld failing to start on boot, but that could be another issue.

Comment 7 Fedora Update System 2016-10-09 06:20:41 UTC
fail2ban-0.9.5-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.