- starting service in normal mode (without forking)
- does not restart if service exited normally (exit-code 0, e.g. stopped via fail2ban-client)
- does not restart if service can not start (exit-code 255, e.g. wrong configuration, etc.)
- service can be additionally started/stopped with commands (fail2ban-client, fail2ban-server)
Currently, if fail2ban is killed (or crashes), its status will be
reported by '/etc/init.d/fail2ban status' as 'running' even though it
is not. Attempting to restart the service also fails, because Gentoo
unsuccessfully tries to stop the service.
By using start-stop-daemon and providing a pidfile, Gentoo will
instead report the status as 'crashed' and allow the service to be
restarted as normal.
These fixes are pretty pedantic, but they do simplify the script a
little.
* Checking the existence of a file/directory before creating/deleting
it adds complexity and raciness. There are better options.
* mkdir -p does the job of making sure a directory exists. (It only
fails if there's a filesystem error or something.)
* Likewise, rm -f doesn't fail if the file doesn't exist.
* rm -r isn't neccessary because the socket shouldn't be a directory.
(If it is for some reason, that should be an error.)
As a useful side effect, prevents "Unable to contact server. Is it
running?" mails from cron when fail2ban hasn't been (intentionally)
running nor thus logging anything either.
(a) use static-network-up, since it is more generic than the started networking event
(b) do not hook into network deconfiguration to speed up shutdown
(c) expect fork, per the use of the "-f" option
(d) use a variable for the run directory to make changing it simpler
(e) handle the situation of a left over socket file
(f) use the -f option to be able to track the PID
No longer directly exec the server, do not remove the PID file because it is unnecessary to do so. No longer respawns because Upstart can not track the process with the starter command.
Allows perf data from all jails to enable pnp4nagios to display a chart per jail when run with the command:
check_fail2ban -p -w 1 -c 5 -P /usr/bin/fail2ban-client
sample output:
CHECK FAIL2BAN ACTIVITY - CRITICAL - 9 detected jails with 5 current banned IP(s) | apache-noscript.currentBannedIP=0 sendmail.currentBannedIP=0 postfix.currentBannedIP=0 ssh-probe.currentBannedIP=3 ssh-ddos.currentBannedIP=0 apache-multiport.currentBannedIP=0 apache.currentBannedIP=0 ssh.currentBannedIP=2 apache-overflows.currentBannedIP=0
- There was a bug with the old "getpid" function, when running linux containers you can see multiple fail2ban instances on hardware node and could stop one on a random virtual environment
- Added reload and status options
oliverdorn