Onderwerp: Ongelukkig php scriptje crasht standaard DA server

Hallo iedereen

Graag had ik volgend probleem aangekaart:

Het proberen openen van een niet-bestaande map in php, zorgt voor een apache proces dat ongeveer 90% van de cpu gebruikt en, hoe langer het loopt, ook steeds meer geheugen gebruikt. Een dergelijk proces blijft draaien tot het manueel wordt afgesloten of het hele boeltje uiteindelijk crasht. Geheugenbeperkingen en timeouts die zijn ingesteld in php, lijken niks uit te halen.

Gaat om een vrij standaard directadmin server met Apache 2.2.27, php 5.3.28 en suPHP 0.7.1.

Een identiek scriptje zorgde in vorige versies van Apache (en php) eveneens voor een hoge load, maar slechts tijdelijk. Dergelijke processen werden na een tijdje automatisch beëindigd en de server ondervond er verder geen hinder van.

Iemand suggesties? Een gekend probleem?

Mvg
Christophe

Oorspronkelijk geplaatst door Christophe1

Hallo iedereen

Graag had ik volgend probleem aangekaart:

Het proberen openen van een niet-bestaande map in php, zorgt voor .....

Iemand suggesties? Een gekend probleem?

Uuum ja, een check inbouwen om te zien of de directory effectief bestaat voor je er iets gaat mee doen .

Code:

<?php
$dir = '/this/directory/does/not/exist';

if (file_exists($dir)) {
    echo "The directory $dir exists";
} else {
    echo "The directory $dir does not exist";
}
?>

Of als je echt hardcore wil gaan een try/catch inbouwen met exceptions (dat zoude eigenlijk alle software/programmeurs moeten doen).

Dank je wel voor de snelle reactie.

Vanuit programmeer oogpunt inderdaad een goed idee om voor het openen van een map te controleren of die wel bestaat, maar waar het om gaat is dat de server blijkbaar zomaar crasht door dergelijke ongelukkige scriptjes. Klanten gebruiken wel vaker scripts die je eigenlijk liever niet wil draaien...

Oorspronkelijk geplaatst door Christophe1

Dank je wel voor de snelle reactie.

Vanuit programmeer oogpunt inderdaad een goed idee om voor het openen van een map te controleren of die wel bestaat, maar waar het om gaat is dat de server blijkbaar zomaar crasht door dergelijke ongelukkige scriptjes. Klanten gebruiken wel vaker scripts die je eigenlijk liever niet wil draaien...

Dan heb je nog opties genoeg om dat tegen te gaan, ik noem er enkele op: cagefs, ulimits (moet je wel php als user draaien), psacct, jailed, ... of je maakt zelf een scriptje wat bvb elke minuut door middel van cron een "ps aux | grep php" doet en elk script dat meer dan XXMB verbruikt of langer dan XX minuten runt geef je een kill -9.

Oorspronkelijk geplaatst door The-BosS

(dat zoude eigenlijk alle software/programmeurs moeten doen).

Dat vind ik toch redelijk kort door de bocht...
Het opvangen van exceptions is 'duur'. Als het om eenvoudige checks die vaak falen is een 'if' doorgaans toch beter.

Oorspronkelijk geplaatst door DenBeke

Dat vind ik toch redelijk kort door de bocht...
Het opvangen van exceptions is 'duur'. Als het om eenvoudige checks die vaak falen is een 'if' doorgaans toch beter.

En een volledige server die crashed is dan wel acceptabel? Ik zeg toch ook niet dat je elke if, case, while, ... in een apparte try/catch moet steken, maar je kunt wel het grootste stuk van je code waar geen controle op plaats vindt in een try/catch zetten.

Uiteraard is dat beter een try/catch te hebben dan helemaal niets!
Ik had uit je eerste post gewoon opgemaakt dat je try/catch altijd beter achtte dan checken met een if/else...

Met je tweede bericht ben ik het dus wel zeker eens

Oorspronkelijk geplaatst door Christophe1

Hallo iedereen

Graag had ik volgend probleem aangekaart:

Het proberen openen van een niet-bestaande map in php, zorgt voor een apache proces dat ongeveer 90% van de cpu gebruikt en, hoe langer het loopt, ook steeds meer geheugen gebruikt. Een dergelijk proces blijft draaien tot het manueel wordt afgesloten of het hele boeltje uiteindelijk crasht. Geheugenbeperkingen en timeouts die zijn ingesteld in php, lijken niks uit te halen.

Gaat om een vrij standaard directadmin server met Apache 2.2.27, php 5.3.28 en suPHP 0.7.1.

Een identiek scriptje zorgde in vorige versies van Apache (en php) eveneens voor een hoge load, maar slechts tijdelijk. Dergelijke processen werden na een tijdje automatisch beëindigd en de server ondervond er verder geen hinder van.

Iemand suggesties? Een gekend probleem?

Mvg
Christophe

Los van de controle zou dit niet PHP moeten opslokken en zou je een fout in PHP krijgen. Heb je een code voorbeeld?

Code voorbeeld:

<?php

$dir = "onbestaande-map";

$dh = opendir($dir);
while (false !== ($filename = readdir($dh)))
{
$files[] = $filename;
}

?>

In het proces-overzicht duikt zoals verwacht een proces op dat draait onder de user van de hostingaccount en hier zie ik dus ook welk script voor problemen zorgt (laat ons dit proces 1 noemen). Naast dit 1ste proces, is het een ander proces dat draait onder user Apache dat voor de hoge load zorgt (laat ons dit proces 2 noemen).

Normaalgezien wordt proces 1 na een tijdje gestopt door de beperkingen die zijn ingesteld in php.ini, waardoor proces 2 vervolgens normaliseert.

Het script in kwestie waaruit ik bovenstaand stukje code heb gekopieerd, draait al jaren en zorgde nooit voor problemen.

Sinds ik Apache heb geupdate naar versie 2.2.27 (en ik tegelijkertijd ook php heb geupdate naar versie 5.3.28 - ik weet niet in hoeverre dit er eventueel ook mee te maken zou kunnen hebben), wordt proces 1 niet meer gestopt door de beperkingen die zijn ingesteld in php.ini en blijft proces 2 draaien tot de server crasht.

Oorspronkelijk geplaatst door Christophe1

Code voorbeeld:



In het proces-overzicht duikt zoals verwacht een proces op dat draait onder de user van de hostingaccount en hier zie ik dus ook welk script voor problemen zorgt (laat ons dit proces 1 noemen). Naast dit 1ste proces, is het een ander proces dat draait onder user Apache dat voor de hoge load zorgt (laat ons dit proces 2 noemen).

Normaalgezien wordt proces 1 na een tijdje gestopt door de beperkingen die zijn ingesteld in php.ini, waardoor proces 2 vervolgens normaliseert.

Het script in kwestie waaruit ik bovenstaand stukje code heb gekopieerd, draait al jaren en zorgde nooit voor problemen.

Sinds ik Apache heb geupdate naar versie 2.2.27 (en ik tegelijkertijd ook php heb geupdate naar versie 5.3.28 - ik weet niet in hoeverre dit er eventueel ook mee te maken zou kunnen hebben), wordt proces 1 niet meer gestopt door de beperkingen die zijn ingesteld in php.ini en blijft proces 2 draaien tot de server crasht.

Het probleem met je code is dat je een loop veroorzaakt die niet stopt. Daarom moet je een check inbouwen of de map wel bestaat. Met PHP 5.4.24 (zonder Apache aan te raken) heb je hetzelfde probleem.

Normaal staat PHP ingesteld om na 30 seconden te stoppen of kom je tegen het geheugenlimiet aan. Hier gaan dus een aantal dingen fout:
1. Slecht programmeerwerk: altijd validatie uitvoeren voordat je daadwerkelijk iets met het stukje code doet.
2. Zorg dat die beperkingen gehandhaafd worden. Het kan zijn dat ergens in het script of een .htaccess dit tegen gegaan wordt.

De beperkingen gelden ook voor cli commando's tenzij je afwijkende instellingen geeft bij de commando.

Ik weet dat dit slecht programmeerwerk is, maar dat is het punt hier niet. Scriptje is gewoon een voorbeeld.

Feit is dat de server blijkbaar crasht door het eerste het beste ongelukkige scriptje van een klant. En dat sinds de update naar apache 2.2.27 en php 5.3.28. Voor deze update is er een nooit een probleem geweest, werden deze scripts met oneindige loop correct automatisch afgesloten.

Verder geen speciale code of htaccess bestanden die instellingen overrulen. Mensen met een min of meer standaard DA server die met deze versies van apache en php werken, probeer gerust zelf; plak m'n voorbeeldje even in een bestand, voer het via je browser uit en je zal zien...

Oorspronkelijk geplaatst door Christophe1

Ik weet dat dit slecht programmeerwerk is, maar dat is het punt hier niet. Scriptje is gewoon een voorbeeld.

Feit is dat de server blijkbaar crasht door het eerste het beste ongelukkige scriptje van een klant. En dat sinds de update naar apache 2.2.27 en php 5.3.28. Voor deze update is er een nooit een probleem geweest, werden deze scripts met oneindige loop correct automatisch afgesloten.

Verder geen speciale code of htaccess bestanden die instellingen overrulen. Mensen met een min of meer standaard DA server die met deze versies van apache en php werken, probeer gerust zelf; plak m'n voorbeeldje even in een bestand, voer het via je browser uit en je zal zien...

Zie daarvoor

2. Zorg dat die beperkingen gehandhaafd worden. Het kan zijn dat ergens in het script of een .htaccess dit tegen gegaan wordt.

De loop zal een een geheugen limiet halen of de uitvoertijd tenzij deze enorm hoog gezet zijn. Daar moet je naar kijken en die limieten zijn er met een reden. Dan krijg je met Apache het volgende in de logs:

Code:

[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Warning:  readdir() expects parameter 1 to be resource, boolean given in /path/to/file.php on line 6
[Sat Apr 19 10:43:30 2014] [error] [client ip] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /path/to/file.php on line 6

In het proces-overzicht duikt zoals verwacht een proces op dat draait onder de user van de hostingaccount en hier zie ik dus ook welk script voor problemen zorgt (laat ons dit proces 1 noemen). Naast dit 1ste proces, is het een ander proces dat draait onder user Apache dat voor de hoge load zorgt (laat ons dit proces 2 noemen).

Draai je mod_ruid?

Probleem is net dat de ingestelde limieten niet gehandhaafd worden...
Voor de update van apache en php wel.

In de logs lijk ik deze errors overigens niet te krijgen.

Draai geen mod_ruid. Wel suPHP.

Oorspronkelijk geplaatst door Christophe1

Probleem is net dat de ingestelde limieten niet gehandhaafd worden...
Voor de update van apache en php wel.

In de logs lijk ik deze errors overigens niet te krijgen.

Draai geen mod_ruid. Wel suPHP.

Stuur anders een pb dan kijk ik hier even naar.

Hier ook geen einde door max execution time, maar wel:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 36 bytes)