2

I have a debian server newly installed yesterday evening. I used an image called debian-7.0-amd64-minimal from my hoster. Just installed apache2, mysql, php, vim, lynx and configured a few webpages. Afterwards I configured a crontab (which runs every 10mins). I had a similar issue before (I thought reinstalling might fix it).

After a few hours the server crashes somehow. I can't reach the webserver, can't access the machine via ssh but somehow it still runs. I can see the machine running in the web-interface from my hoster. Still since I can't access any service I have to restart it (via the web-interface provided by my hoster).

After restarting it I always checked all logs in /var/log having relevant timestamps. However there is only one sporadic error

[Fri Mar 28 12:40:17 2014] [error] [client x.x.x.x] PHP Warning:  file_get_contents(http://www.bloomberg.com/quote/DAX:IND): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known

This is caused by a php-script called via crontab (a webpage is invoked using lynx) The DNS server is the one from google 8.8.8.8 . However this happens only sometimes and usually the services continue working after that. This is why I guess this is a different issue. I disabled the crontab after the last crash and update this post if the issue resolves itself now.

The other thing which makes me believe that the server not totally crashes is that those crontabs still continue to work

Mar 28 10:00:01 aryx /USR/SBIN/CRON[10947]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:00:06 aryx /USR/SBIN/CRON[10946]: (CRON) info (No MTA installed, discarding output)
Mar 28 10:09:01 aryx /USR/SBIN/CRON[11068]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
Mar 28 10:10:01 aryx /USR/SBIN/CRON[11088]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:10:21 aryx /USR/SBIN/CRON[11087]: (CRON) info (No MTA installed, discarding output)
Mar 28 10:20:01 aryx /USR/SBIN/CRON[11221]: (root) CMD (lynx -dump http://[webpage]/cron/cronjob.php)
Mar 28 10:20:21 aryx /USR/SBIN/CRON[11220]: (CRON) info (No MTA installed, discarding output)

even though the webserver already crashed (or whatever crashed by that time) somewhere between 10:00 and 10:10 (at which time the next cron call was executed)

[webpage]:80 [ip-address] - - [28/Mar/2014:09:50:01 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"
[webpage]:80 [ip-address] - - [28/Mar/2014:10:00:01 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"
[webpage]:80 [ip-address] - - [28/Mar/2014:12:00:02 +0100] "GET /cron/cronjob.php HTTP/1.0" 200 208 "-" "Lynx/2.8.8dev.12 libwww-FM/2.14 SSL-MM/1.4.1 GNUTLS/2.12.18"

The one irregularity though also occurs before 10am

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

Any suggestions what could be wrong?

update: Using plog, the only noticeable event around the crash-time (which was between 19:31 and 32) is the logfile of a apache process:

3-28 19:31   S     20         0s      1   185.34MB     7.46MB 96.2%     1012kB    16.66MB    17.73MB         429       0
3-28 19:32   S     20         0s      1   187.50MB     9.68MB 89.1%     1804kB    16.79MB    17.86MB        1281       0
3-28 19:33   S     20         0s      1   187.50MB     9.68MB 89.1%     1804kB    16.79MB    17.86MB        1281       0
  • You might try using plog to monitor apache and sshd at short intervals (1-5 minutes) to see when they fail and if anything unusual was building up before that. – goldilocks Mar 28 '14 at 12:48
0

The problem actually was not the server itself. The server was a virtual private server and had an IP assigned that was used by another server as well in the network. That's why there were some random connectivity problems!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.