From: Ben J. <be...@in...> - 2013-02-19 18:37:54
|
On 2/19/2013 10:20 AM, Fabian Wenk wrote: > Hello Ben > > On 19.02.2013 16:02, Ben Johnson wrote: >> On 2/19/2013 9:13 AM, Fabian Wenk wrote: > >>> Gentoo is also doing the transition from /var/run to the tmpfs >>> /run and so /var/run is just a symlink pointing to /run. But as >>> /run is a tmpfs, it is empty again after a system reboot. >>> >>>> ah -- then I have no clue where /var/run/fail2ban is gone since since >>>> 0.8.2 init script creates it: >>> >>> @Ben, could you check with 'ls -l /var/run' (without a / after >>> run) if this already is a symlink to /run. if yes, check e.g. >>> with 'df -hl | grep /run' what kind of filesystem /run is. >> >> I checked this out and it's not a symlink; it's a real directory. > > Could you check if eventually /var/run is also a tmpfs? Did it > fail after you have rebooted your system? I don't see any indication that /var/run is a tmpfs. Here's the output from "df": # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/vzfs 80000000 47984964 32015036 60% / /dev/simfs 80000000 47984964 32015036 60% /tmp /dev/simfs 80000000 47984964 32015036 60% /var/tmp The contents of /etc/fstab are: proc /proc proc defaults 0 0 none /dev/pts devpts rw 0 0 /dev/vzfs / reiserfs rw,usrquota,grpquota 0 0 >>>> so I would look for someone who destroyed it for you! ;) > >> A better question might be, why does fail2ban not recreate this >> directory if it's missing, instead of "failing" outright. This may be a >> clear-cut case of ban2fail! :) >> >> In all seriousness, though, is there some reason for which this >> directory is not recreated if necessary? How is it created in the first >> place? During installation? > > During the installation the directory is created from the .deb > package, e.g. aptitude or apt-get does create it according to the > post script in the .deb. > > On system boot, or start of fail2ban with '/etc/init.d/fail2ban > start' (which this newish 'service fail2ban start' also uses) > this script should check it. Eventually adding something like > this at top in the start section could help: > > if [ ! -d /var/run/fail2ban ] ; then > mkdir /var/run/fail2ban > fi Adding these lines to the init script seems like a good idea. I'll add them to my own copy right now, but it would be nice to have assurance that this change will be committed to the source code. The theory that a reboot is what broke fail2ban has merit. I dug back through my Logwatch reports and discovered that fail2ban stopped banning on Feb. 11. Take a look at the mod-dates for the directories in /var/run: # ls -lah /var/run total 76K drwxr-xr-x 12 root root 4.0K Feb 19 09:04 . drwxr-xr-x 17 root root 4.0K Dec 20 10:14 .. drwxr-xr-x 2 amavis amavis 4.0K Feb 11 21:24 amavis drwxr-xr-x 2 root root 4.0K Feb 11 21:24 apache2 -rw-r--r-- 1 root root 5 Feb 17 00:26 apache2.pid drwxr-xr-x 2 clamav root 4.0K Feb 17 00:26 clamav -rw-r--r-- 1 root root 6 Feb 11 21:22 crond.pid ---------- 1 root root 0 Feb 11 21:22 crond.reboot drwxr-xr-x 3 root root 4.0K Feb 11 21:22 dovecot drwxr-xr-x 2 root root 4.0K Feb 19 06:48 fail2ban -rw-r--r-- 1 root root 161 Feb 19 09:04 motd drwxr-xr-x 2 mysql root 4.0K Feb 11 21:22 mysqld drwxr-xr-x 2 root root 4.0K Feb 11 21:22 network -rw-r--r-- 1 root root 4 Feb 11 21:22 ntpd.pid drwx------ 2 root root 4.0K Feb 19 09:24 pure-ftpd drwxrwxr-x 2 root utmp 4.0K Feb 11 21:21 screen drwxr-xr-x 2 root root 4.0K Feb 11 21:21 sshd -rw-r--r-- 1 root root 6 Feb 11 21:22 sshd.pid -rw-r--r-- 1 root root 6 Feb 11 21:22 syslogd.pid -rw-rw-r-- 1 root utmp 3.0K Feb 18 17:29 utmp All evidence points to the fact that a reboot was performed Feb 11, shortly after 21:00, which sounds about right (I was doing some maintenance that required a reboot that night). The question remains: how was this directory deleted in the first place, if no tmpfs is at play? As I stated earlier, fail2ban *did* log its shutdown sequence when the system notified it was going down for reboot; is there anything in the source code that would remove the /var/run/fail2ban directory under certain shutdown conditions? Perhaps this point is moot, as long as your modification is added to the init script: if [ ! -d /var/run/fail2ban ] ; then mkdir /var/run/fail2ban fi Thanks for the viable workaround, Fabian! -Ben > > bye > Fabian > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |