ERPNext.com Frappe Cloud Support Partners Foundation Frappe School

Request time out Error - Site running very slow

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

1 Like

Thats generally because of unrotated logs.

3 Likes

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

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

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

1 Like

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

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

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