Quote
I can not confirm that.
Works without problems.
same kernel version?
If I start with all apache filters enabled I found this in the log:
and the F2B start comand hungs, I can wait 30 minutes nothing happens
I also checked the size off the logfiles, but there is no file greater than 50MB ...
it always stops at the same domain error log:
the pid and sock file is available under /var/run/fail2ban
but I have no response from my shell start comand ... I always have to press STRG+C
below is how it looks without any apache logfile, in this case I am able to stop, start and restart fail2ban
if I activate any filter of apache fex. apache overloads or any other with the logpath /var/log/apache2/*/error.log
it wont start or restart, I have to kill all processes by hand and disable the apache filter before I can start F2B.
Before the kernel update I never had any problems with fail2ban ...
Debain Wheezy, Kernel 3.2.0-4-amd64
can anyone confirm this problem?
Plugins ??? You want surely say "the filters"... What are the filters which doesn't work anymore?. Post them here.
BTW: Post moved in the correct section
this is just a sample, ALL other apache filters do not work anymore, I posted it here because I do not know if there is a problem with the location of the apache logs
please Restart fail2ban and controlling your fail2log.
for error 100 see
http://unix.stackexchange.com/…bian-lenny-moved-ssh-port
no, that is not the reason I have disabled ssh plugin or set to ssh instead of port 2200, I can not start fail2ban with apache plugins enabled ... could this be a problem with the gamin server?
what the hack is jail xxx uses gamin?
this is the first time i see this in the F2B logs ...
i can use only this two plugins ... all other apache plugin wont start with fail2ban anymore:
[roundcube]
enabled = true
port = http,https
filter = roundcube
logpath = /var/www/imscp/gui/public/tools/webmail/logs/errors
maxretry = 6
[apache-badbots]
enabled = true
port = http,https
filter = apache-badbots
logpath = /var/log/apache2/*/access.log
maxretry = 1
findtime = 3600
bantime = 2592000
this is strange:
debian wheezy
after reboot because of a kernel and php update, fail2ban wont start ...
it seems it can not handle the apache logfiles or non-existing logfiles
if I disable all apache plugins from fail2ban it starts ... I dont know if this is a problem with the logpath or non-exist logfiles
any idea?
my log path and config:
habe auch das gleiche Problem, der Restore bricht ab und setzt die Domain auf Fehlerstatus ...
die Fehlermeldung kannst Du im PMA unter Domains > Status
wieder auf ok setzen
das mit dem Restore scheint ein Bug zu sein ...?
I'm not quite sure about the reason for the crash ... could be a package or configuration problem
I had already tested migration to mariadb in a Vbox with same database and it worked well, maybe the special my.cnf from mysql is not compatible with mariadb ...
But I guess it would be a good idea to test in a VM with same packages and config files.
OK, could be solved by importing complete imscp sql backup ...
but for the upgrade, is it possible testing an upgrade w/o changing files as a dry run?
