| Summary: | Fail2ban prevents restarting firewalld | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | kakoskin |
| Component: | fail2ban | Assignee: | Orion Poplawski <orion> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 24 | CC: | athmanem, axel.thimm, jonathan.underwood, orion, redhat-bugzilla, vedran, vonsch |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | fail2ban-0.9.5-3.fc24 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-09 06:20:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 1317240 | ||
| Bug Blocks: | |||
| Attachments: | |||
Created attachment 1204532 [details]
journalctl -PID=1 for failed restart and following restart with fail2ban stopped.
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. Can confirm as well. 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. 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 Seems to fix the issue. Though I still get firewalld failing to start on boot, but that could be another issue. 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. |
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.