Ich habe gestern Abend einen Debian-Server neu installiert. Ich habe ein Image namens debian-7.0-amd64-minimal von meinem Hoster verwendet. Ich habe gerade Apache2, MySQL, PHP, Vim, Lynx installiert und ein paar Webseiten konfiguriert. Danach habe ich eine Crontab konfiguriert (die alle 10 Minuten ausgeführt wird). Ich hatte vorher ein ähnliches Problem (ich dachte, eine Neuinstallation könnte es beheben).
Nach ein paar Stunden stürzt der Server irgendwie ab. Ich kann den Webserver nicht erreichen, kann nicht per SSH auf die Maschine zugreifen, aber irgendwie läuft sie trotzdem. Ich kann sehen, dass die Maschine in der Weboberfläche meines Hosters läuft. Da ich aber trotzdem auf keinen Dienst zugreifen kann, muss ich sie neu starten (über die Weboberfläche meines Hosters).
Nach dem Neustart habe ich immer alle Protokolle in /var/log mit relevanten Zeitstempeln überprüft. Es gibt jedoch nur einen sporadischen Fehler
[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
Dies wird durch ein PHP-Skript verursacht, das über Crontab aufgerufen wird (eine Webseite wird über Lynx aufgerufen). Der DNS-Server ist der von Google 8.8.8.8. Dies passiert jedoch nur manchmal und normalerweise funktionieren die Dienste danach weiter. Deshalb vermute ich, dass dies ein anderes Problem ist. Ich habe die Crontab nach dem letzten Absturz deaktiviert und aktualisiere diesen Beitrag, wenn sich das Problem jetzt von selbst löst.
Der andere Grund, der mich glauben lässt, dass der Server nicht komplett abstürzt, ist die Tatsache, dass diese Crontabs weiterhin funktionieren.
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)
obwohl der Webserver bereits irgendwo zwischen 10:00 und 10:10 (zu diesem Zeitpunkt wurde der nächste Cron-Aufruf ausgeführt) abgestürzt ist (oder was auch immer zu diesem Zeitpunkt abgestürzt ist)
[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"
Die einzige Unregelmäßigkeit tritt jedoch auch vor 10 Uhr auf
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)*
Irgendwelche Vorschläge, was falsch sein könnte?
aktualisieren: Bei Verwendung von plog ist das einzige erkennbare Ereignis rund um den Absturzzeitpunkt (der zwischen 19:31 und 32 lag) die Protokolldatei eines Apache-Prozesses:
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
Antwort1
Das Problem lag eigentlich nicht am Server selbst. Der Server war ein virtueller privater Server und hatte eine zugewiesene IP, die auch von einem anderen Server im Netzwerk verwendet wurde. Deshalb gab es einige zufällige Verbindungsprobleme!