Fail2ban wont start

restapps just upgraded but still not running as per dashboard

restarted restapps and xmpp manually via cli and all seems to be running now

1 Like

Just upgraded to 15 - running sysadmin and Fail2Ban not starting for me too.
[[email protected] ~]# systemctl status fail2ban.service -l
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Fri 2021-07-30 14:39:43 PDT; 1min 23s ago
Process: 10679 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255)
Process: 10677 ExecStartPre=/bin/mkdir -p /var/run/fail2ban (code=exited, status=0/SUCCESS)

Jul 30 14:39:43 systemd[1]: Failed to start Fail2Ban Service.
Jul 30 14:39:43 systemd[1]: Unit fail2ban.service entered failed state.
Jul 30 14:39:43 systemd[1]: fail2ban.service failed.
Jul 30 14:39:43 systemd[1]: fail2ban.service holdoff time over, scheduling restart.
Jul 30 14:39:43 systemd[1]: Stopped Fail2Ban Service.
Jul 30 14:39:43 systemd[1]: start request repeated too quickly for fail2ban.service
Jul 30 14:39:43 systemd[1]: Failed to start Fail2Ban Service.
Jul 30 14:39:43 systemd[1]: Unit fail2ban.service entered failed state.
Jul 30 14:39:43 systemd[1]: fail2ban.service failed.

Tried the zulu command and /var/www/html/admin/modules/sysadmin/hooks/fail2ban-apache-config attempt. None have worked.

Still same issues. Systemadmin is now fixed from edge update, but fail2ban remains broken after restore. Tried all methods above

Had the same problem after last yum update and full Freepbx update to, tried to reinstall Fail2ban and tinkered around a bit to no avail,
Then tried the manual /var/www/html/admin/modules/sysadmin/hooks/fail2ban-apache-config and it worked like a charm. all is up and running now !!

So as of late yesterday, System Admin ver. was promoted to stable which should resolve the fail2ban starting issue. Upgrading sysadmin can be done in the conventional way using the GUI or you can run:

fwconsole ma upgrade downloadinstall sysadmin --tag

confirm installed version with:

fwconsole ma list | grep sysadmin

confirm fail2ban status with

systemctl status fail2ban

restart fail2ban with

systemctl restart fail2ban
1 Like

I’ve got a fresh install from last night with this same issue.
| sysadmin |
fail2ban-fpbx.noarch 0.8.14-76.sng7 @anaconda/2011

I had to run the following to fix it as others suggested :

1 Like

No fix yet for me. I’ll trying moving to a new vm I guess.

I wonder what

sudo fail2ban-client restart

would return, apparently the systemd fail2ban.service is disabled in the distro so something is otherwise doing fail2ban-client -x start or systemctl start fail2ban (both of which would fail if it is actually already running) , as to your previous iptables status, then iptables -L -n before and after might be helpful

Where I to suggest a solution . . .

systemctl stop fail2ban.service
systemctl start yourfirewall.service
systemctl start fail2ban.service

of course yourfirewall.service should not be messing with fail2ban in any way (tested working on f2b >= 0.8 with its distributed systemd service installed for “lot’s of years”)

ERROR Unable to contact server. Is it running?

Try Fail2ban-client -x start

or fail2ban-client -x -f restart to clean out the run file and run in the foreground

ERROR Found no accessible config files for ‘filter.d/zulu’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘zulu’. Skipping…

This is why I originally uninstalled Zulu. I just tried reinstalling it and running the command again. Same result.

Usage: /bin/fail2ban-client [OPTIONS]

Fail2Ban v0.8.14 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.

-c configuration directory
-s socket path
-p pidfile path
-d dump configuration. For debugging
-i interactive mode
-v increase verbosity
-q decrease verbosity
-x force execution of the server (remove socket file)
-h, --help display this help message
-V, --version print the version

start starts the server and the jails
reload reloads the configuration
reload reloads the jail

and so on

I guess that version is too old for running in the foreground :wink:

Perhaps you could restart it with -xvvv and either it might on the screen or you could tail the log file :wink:

Edit jail.local and remove the Zulu jail


That seems to have done it on this server. Intrusion detection rules were of course wiped out but syncing it with the trusted networks and registered extensions works now.

Will go check the other servers that were having this issue and report back. Thanks.

In case this fixes anyone else’s issue my sysadmin module was updated via the GUI to the edge track (forgot that was set to edge mode) to version . I commented out the lines about the zuu jail in /etc/fail2ban/jail.local. Then ran fail2ban-client -x start and now it appears to be working. Will see if CPU usage goes up again.

1 Like

It will always be higher if you restart it later in the day as your logs grow, well written logrotate mitigates a little in the early morning by resetting the log files being watched to 0 length , but while fail2ban remains at 0.8 you are hamstrung until Sangoma takes this problem seriously and decouples “intrusion detection” from it’s commercial “firewall” or at least makes them play well together. IMHO F2B >=0.10 would be a good place for them to start :wink: (as far is I can experiment, badly written “jails” are no longer fatal, just ignored)

fwconsole ma downloadinstall sysadmin --tag -f
```did it for me. Stepping back from However same error before in ..71.
I'm not using Zulu.
see CLI, where sysadmin_fail2ban is updated.

No repos specified, using: [standard,extended,commercial] from last GUI settings

Starting module download from ...
 852497/852497 [============================] 100%
Finished downloading
Module successfully downloaded
Updating tables sysadmin_options, sysadmin_update_log, sysadmin_fail2ban...Done
Sangoma PnP Server activated
Generating CSS...Done
Module sysadmin version successfully installed
Updating Hooks...Done
Chowning directories...Done
[[email protected] fail2ban]# systemctl start fail2ban.service
[[email protected] fail2ban]# 

I will not upgrade to ..72 again until green light from Lorne

I’ve got another with a similar problem but this time it’s got a problem with apache-api jail. Is that safe to comment out?

fail2ban-client -x start
ERROR Found no accessible config files for ‘filter.d/apache-api’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘apache-api’. Skipping…

Unfortunately as yet everything posted in this thread (and other similar ones) are closed source as to resolution , so you will have to add your problems behind the dozens of other unresolved dependencies that await attention by Sangoma.

( crocodiles have alarm clocks, a quick ameliorative I can suggest is to stop listening to UDP/5060 before it bites you, and sngrep will show all the exposure you already have, because your firewall is apparently broken and every ‘bot’ and their ‘controller’ knows it)