Request time out Error - Site running very slow

Install / Update Setup
1

I am getting Request Time Out error while performing any action.I have found file2ban utilizing my 100% CPU. Kindly Help

file2ban
file2ban1319×762 257 KB

1 Like
2

Thats generally because of unrotated logs.

3 Likes
3

Thank you Vamyip.
this is my logrotate file:

/var/log/fail2ban.log {

weekly
rotate 4
compress

delaycompress
missingok
postrotate
    fail2ban-client flushlogs 1>/dev/null || true
endscript

# If fail2ban runs as non-root it still needs to have write access
# to logfiles.
# create 640 fail2ban adm
create 640 root adm

}

is this is the reason for slow performance of my site?
Regards,

1 Like
4

No. Fail2Ban reads logs configured in for jails (generally nginx and ssh) to identify anomalous traffic. If logs of nginx and ssh are not rotated, they become large and fail2ban takes longer to read those logs.

First verify if any of logs are being rotated. If yes, then need to check why nginx’s logs are not rotated.

2 Likes
5

Thank You VamYip,
System is responding normally after clear my log files.
Thanks for your support.

1 Like
6

Hi,
Can you elaborate more, I have facing same issue, but how to verify this point first, plz detailed steps

then second part also I need a how to steps for that

Thanks a lot
Nofal

1 Like
7

Manually deleted all older logs from system.

  1. cd /home/var/log
  2. ls -lah
  3. find the large size file and clear the content with sudo echo > file name
  4. cd ~/frappe-bench/logs
  5. repeat no 3 (for all .log file)
    Add the below line inside
  6. cd etc/logrotate.d/
  7. sudo nano fail2ban
  8. add this line inside postrotate block
    postrotate
    fail2ban-client flushlogs 1>/dev/null || true
    endscript
2 Likes
8

Found the reason why Nginx (and most of the other logs) were not being rotated on the servers setup before March 2020. It was due to a bug in bench’s letsencrypt setup script causing crontab’s /etc/crontab config to break :exploding_head:. So crontab ignored the file altogether and caused the standard cron jobs (cron.daily, cron.weekly, etc) to fail. Note that custom cron jobs that we setup (using crontab -e) continued to run because they are not referenced via /etc/crontab . This issue affects only those jobs which were referenced via /etc/crontab.

This also explains troublesome behavior of fail2ban upon server restart :face_with_monocle:. Since nginx’s logs weren’t being rotated sometimes fail2ban attempted to read all the log since beginning which caused a prolonged CPU spike. Log Rotation will solve that also. :relaxed:

HTH,
Vamyip

1 Like