0

I have a Ubuntu 12.04 512mb VPS server running on Linode. I have it setup to serve about 6 Wordpress powered websites.

For a few weeks now it has crashed daily, 2-3 times. Linode automatically reboots the machine, but if I disable that I either can't SSH in at all, or if I do, the server responds extremely slowly.

Just last night I switched over everything from Apache to nginx, but that didn't help.

Looking at the log files, the only thing I've found is that the last entry is almost always

Mar 28 06:05:01 cappicola CRON[10852]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Although sometimes that is several minutes before the reboot. Sometimes I also find

Mar 28 06:09:01 cappicola CRON[10860]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)

The only other entries in the log file are postfix and fail2ban related warnings. Any ideas?

Jon
  • 125
  • 1
  • 7

3 Answers3

1

The second log string is caused by your cron activity which looks for idle php-sessions and kills them. To get over this issue, you should edit your /usr/lib/php5/maxlifetime file as specified here (https://stackoverflow.com/questions/3865303/debian-based-systems-session-killed-at-30-minutes-in-special-cron-how-to-overri).

If it doesn't help, you should try to get more statistics on how your system perform before the reboot. To deal with this, please look the answer here (http://www.unix.com/linux/110432-system-getting-crashed.html).

Meriadoc Brandybuck
  • 1,330
  • 9
  • 11
  • Thanks -- it was actually your second tip that did the trick. I found two processes running wild that shouldn't have even been running in the first place. – Jon Apr 05 '13 at 13:40
0

Do you have any monitoring like Zabbix? It will be usefull to log into some stats. You san also use sar(1). How about load average?

0

fail2ban is most likelely the one that freezes the machine.

Try disabling all rules / fail2ban at all and check the reaction. I guess it has something to do with python going nuts, when running as server. Also notice, that the approach to read logfiles can be a degression, in case the logfiles get very big and the system has to load the files into the memory to grep out certain matches.

Also: check the filesystems: [sudo] shutdown -Fr now

moestly
  • 1,188
  • 9
  • 11