I get the following:
$ systemctl status fail2ban.service -l -n 20
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit) since Tue 2015-07-07 03:37:26 CEST; 13min ago
Docs: man:fail2ban(1)
Process: 1260 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255)
Jul 07 03:37:25 zira systemd[1]: Failed to start Fail2Ban Service.
Jul 07 03:37:25 zira systemd[1]: fail2ban.service: Unit entered failed state.
Jul 07 03:37:25 zira systemd[1]: fail2ban.service: Failed with result 'exit-code'.
Jul 07 03:37:26 zira systemd[1]: fail2ban.service: Service hold-off time over, scheduling restart.
Jul 07 03:37:26 zira systemd[1]: fail2ban.service: Start request repeated too quickly.
Jul 07 03:37:26 zira systemd[1]: Failed to start Fail2Ban Service.
Jul 07 03:37:26 zira systemd[1]: fail2ban.service: Unit entered failed state.
Jul 07 03:37:26 zira systemd[1]: fail2ban.service: Failed with result 'start-limit'.
The /var/log/syslog file is more complete and gives the reason of
the error:
Jul 7 03:37:24 zira fail2ban-client[789]: ERROR No file(s) found for glob /var/log/apache*/*error.log
Jul 7 03:37:24 zira fail2ban-client[789]: ERROR Failed during configuration: Have not found any log file for apache-noadmin jail
fail2ban should not refuse to start, but just ignore the jail in such
a case (possibly with some kind of warning).
you say potato and I say potato -- you say "should not", and I say "should" ;-) This is a feature to avoid causing a false sense of protection. If you configure a jail to monitor some files, they must be there, otherwise fail2ban would not pick them up anyhow later and that jail will never be "in effect", although you might be thinking that it is. So consider it a feature. As a workaround you might like to configure your logrotation to re-create empty files (create configuration option in your logrotate configs).
Control: reopen 791640 Control: retitle 791640 fail2ban should report an error when it cannot start No! This is not documented, thus it is not a feature! At least when the user has no way to know that. The problem is that fail2ban doesn't offer any protection at all because it fails silently. So, instead of possibly having one thing broken, one has everything broken!!! There should be a way for the user to know (without any special action on his part) that fail2ban could not start. apache2 isn't installed yet, so that it would not be possible.
brr -- didn't you get a log stating that it failed to start and a reason for the failure stated (as you quoted above)? so disable that jail then!
This is only in the logs. The user isn't supposed to look at the logs each time he boots his machine to check whether some service has refused to start by design. If the goal of the failure is that the user can notice it, then there should be a clear notification in one of the usual methods (e.g. the same behavior when a cron command fails, which is usually a mail). But this means that when I install apache2, I will need to remember to enable it. And if I remove apache2 (and the logs, then useless), I will need to remember to disable this jail again, otherwise fail2ban will start to fail silently again.
it is also on console whenever you are trying to start a misconfigured service (I have tuned up jail.conf to point to a nonexisting file): hopa# service fail2ban start Job for fail2ban.service failed. See 'systemctl status fail2ban.service' and 'journalctl -xn' for details. hopa# /etc/init.d/fail2ban start [....] Starting fail2ban (via systemctl): fail2ban.serviceJob for fail2ban.service failed. See 'systemctl status fail2ban.service' and 'journalctl -xn' for details. failed! does it report a successful start for you? if not -- I would close it (again) since I see no problem. Would apache2 start for you if you have misconfigured one of its hosted domains? the only possible related enhancement I can see is extending config specification to allow for "automatic enable for sections if log files exist", but it needs to be explicit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407404 https://github.com/fail2ban/fail2ban/issues/55 if you feel that this is what you want then I would just merge this one into 407404. if you care to send a PR against upstream -- it might get in ;)
Yes, but this isn't something one usually does. In general, fail2ban is started at boot time. Note also that the systemd log doesn't give the reason. The reason can only be found in /var/log/syslog (the cause seems to be that the error comes from fail2ban-client and not fail2ban.service). error is just due to missing *non-config data*. Similarly, with apache2, if I remove non-config data, apache2 can still start. Yes, thanks, an "enabled=auto" feature would be OK. You can either close this bug or merge it with 407404. I have just subscribed to 407404. BTW, in bug 407404, shouldn't the "forwarded" be updated to the upstream bug? (Or at least give a reference somewhere in the bug.)
forcemerge 407404 791640 forwarded 407404 https://github.com/fail2ban/fail2ban/issues/55 thanks
Dear Customer, We can not deliver your parcel arrived at February 02. Please check the attachment for complete details! Your help is greatly appreciated, Ricky Weeks, UPS Chief Station Manager.
This bug was closed by a spammer in 2017! An no-one noticed.
Let's try again. My first unarchive attempt on 791640 actually unarchived only 407404 (though it is merged with 791640), but this bug got archived again a few minutes later!
This is incredible! While it worked, the bugs are now again archived and closed!
OK, now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791640 shows (again) that the bug is reopened: Control: unarchive 407404 Control: unarchive 791640 Control: reopen 407404 Control: reopen 791640 This is incredible! While it worked, the bugs are now again archived and closed! [...] ------------------------------------------------------------ but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407404 (after a forced reload and a test with lynx and wget) shows that bug 407404 is still archived and closed (last line from 05 Mar 2017).
Each time I unarchive and reopen the bugs, someone is reverting my changes, i.e. the last line on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791640 is back to the "Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 05 Mar 2017 07:25:15 GMT)"!!! Let's reopen again...