[Apache] [PHP] Reactie van server is leeg!

[TheNephilim]

We hebben enkele maanden geleden een website voor een klant afgeleverd. In Wordpress, werkend en al, geen problemen! Goed, de hosting zoals wij dat het liefst zien was niet aanwezig, maar in ons marktsegment is dat meestal niet zo'n probleem.

Nu begin deze week 'doet de website het niet meer'. Dus ik ga kijken en kom erachter dat bepaalde pagina's inderdaad voor problemen zorgen. Alle pagina's waarop een uitgaande request te vinden is, gaan de mist in. Bijvoorbeeld de Thema, Plugins en Update pagina's binnen /wp-admin/. Ook de front page werkt niet, die cURL + OAuth gebruikt om de laatste Twitter berichten van het bedrijf op te halen.

Natuurlijk ga je dan de reqeuest zelf bekijken, maar die is gewoon leeg. Helemaal niks: "Geen gegevens ontvangen"... In de Chrome Network Console krijg ik 'Pending' te zien, maar er komt gewoon niks terug. Als ik in DirectAdmin ga kijken, in de Apache Error Logs is er niets te zien, vreemder zijn de Apache User Logs; ook daar is de request niet te vinden. Requests naar andere pagina's voor en na het bezoeken van (bijv.) /wp-admin/plugins.php staan er wel in.

Ik ben van mening dat de hoster in dit geval een oplossing moet zoeken. De website heeft altijd prima gewerkt en dingen gaan niet vanzelf kapot. Ik vermoed dat 'beveiligingsinstellingen' of een firewall bij de hoster voor problemen zorgen. Maar ze blijven de vinger natuurlijk in mijn richting wijzen.

Kortom; wat denken jullie? Mis ik iets en is het mijn probleem, of moet de hoster hier de stoute schoenen aantrekken?

[Mike2k]

een .htaccess die e.e.a. verkracht ?

[TheNephilim]

Mike2k schreef op donderdag 17 juli 2014 @ 15:15:
een .htaccess die e.e.a. verkracht ?

De .htaccess klopt gewoon, maar die heb ik toch even uitgezet om te kijken of het verschil maakte. Helaas was dit niet de oplossing!

[Morrar]

Is het niet gewoon het probleem dat er niet naar een index bestand wordt gezocht? Klinkt als een redirect of rewrite die de verkeerde kant op gaat. Lijkt me inderdaad iets om tenminste samen met je host te onderzoeken.

[jaapenstaart]

Staat de PHP error reporting / display errors aan?

Mogelijk een PHP-fout, terwijl de PHP error reporting uit staat. Dan krijg je ook vrij weinig terug van de server.

[Herko_ter_Horst]

Kun je niet even een debug-pagina op de site zetten om voor jezelf wat dingen uit te gaan sluiten?

offtopic:
Als de hoster al iets moet aantrekken, dan is het het boetekleed. De stoute schoenen trek je aan als je iets gewaagds/brutaals gaat doen.

[Morrar]

jaapenstaart schreef op donderdag 17 juli 2014 @ 15:19:
Staat de PHP error reporting / display errors aan?

Mogelijk een PHP-fout, terwijl de PHP error reporting uit staat. Dan krijg je ook vrij weinig terug van de server.

Maar dan staan de HTTP requests wel gewoon in de logs en zou de error ook terug te vinden moeten zijn in de error log.

Tenminste, zo werkt het bij mijn host die ook alle online error reporting uit heeft gegooid (begrijpelijk, maar soms wel behoorlijk irritant).

[TheNephilim]

Morrar schreef op donderdag 17 juli 2014 @ 15:21:
[...]


Maar dan staan de HTTP requests wel gewoon in de logs en zou de error ook terug te vinden moeten zijn in de error log.

Tenminste, zo werkt het bij mijn host die ook alle online error reporting uit heeft gegooid (begrijpelijk, maar soms wel behoorlijk irritant).

Precies, dan zou ik op z'n minst een 'Status 500: Server error!' terug moeten krijgen.

Herko_ter_Horst schreef op donderdag 17 juli 2014 @ 15:20:
Kun je niet even een debug-pagina op de site zetten om voor jezelf wat dingen uit te gaan sluiten?

Misschien geen verkeerd idee, dan weet ik welke gebruikte 'functie' niet werkt.

[HamuNaptra]

Hoi TheNephilim,

Heb je al getest met een kopie van de website op een andere server?
Indien dit gewoon werkt, stuur dan een nette mail naar de hoster om dit verder uit te zoeken en verwijs tegelijk naar de werkende kopie

[TheNephilim]

HamuNaptra schreef op donderdag 17 juli 2014 @ 15:30:
Heb je al getest met een kopie van de website op een andere server?
Indien dit gewoon werkt, stuur dan een nette mail naar de hoster om dit verder uit te zoeken en verwijs tegelijk naar de werkende kopie

Nee, de website heeft immers gewoon gewerkt. Standaard functies binnen Wordpress gaan al fout, dus een kopie maken zou niet nodig zijn. Dan eerdere een kale Wordpress installatie op dezelfde server.

---

Warning: phpinfo() has been disabled for security reasons in /home/***/domains/***.nl/public_html/info.php on line 1

Tjah... dan weet je eigenlijk al genoeg.

[Bart]

Is er niet gewoon firewalling actief die uitgaande requests naar poort 80/443 blokkeert?

[TheNephilim]

Na wat exit('Fine'); in /wp-admin/update-core.php geplaatst te hebben, kwam ik erachter dat het in /wp-admin/admin.php misgaat op regel 178

Als ik daar een exit('Fine'); plaats krijg ik netjes 'Fine' te zien, maar daaronder gaat het sowieso mis. Waar dan ook....

Dus binnen if ( isset($plugin_page) ) { en we krijgen geen response terug van de server.

[Janoz]

TheNephilim schreef op donderdag 17 juli 2014 @ 15:36:
Nee, de website heeft immers gewoon gewerkt. Standaard functies binnen Wordpress gaan al fout, dus een kopie maken zou niet nodig zijn. Dan eerdere een kale Wordpress installatie op dezelfde server.

Tja, het werkte, en daarna werkte het niet. Daartussen is iets veranderd. Wanneer je zelf een server op kunt zetten waarop je een kopie van jou site draait kun je controleren of het aan de applicatie, of aan de inrichting van de server ligt. Je hebt iig een stok om de hoster mee te slaan.

[CyberJack]

Memory probleem?

De regel if ( isset($plugin_page) ) { wordt namelijk eerder ook al gebruikt en daar levert het geen probleem op.

[HamuNaptra]

Misschien een mislukte hackpoging op je WP installatie?

Probeer alleszins gewoon de originele bestanden eens terug te zetten.
Ik neem aan dat het nu belangrijker is om een werkende website te hebben, dan enkele uren/dagen te verliezen met de rootcause te zoeken.

[Solopher]

Heb je toevallig je wp-config al bekeken? Laatst was een server waar een site opstaat die ik beheer slachtoffer worden van een hack.

In de wp-config kon ik helemaal naar rechts scrollen waar de nodige code was geïnjecteerd.

[kwaakvaak_v2]

en een php error hoeft niet per saldo een 500 op te leveren, hangt er maar net vanaf hoe deze eruit valt. Op sommige hosts wil PHP soms onverklaarbaar er wel eens uit klappen met een segfault, en de komt niet in de apache log, niet in de php log maar wel in de messages of syslog terecht.

[TheNephilim]

Janoz schreef op donderdag 17 juli 2014 @ 15:56:
[...]

Tja, het werkte, en daarna werkte het niet. Daartussen is iets veranderd. Wanneer je zelf een server op kunt zetten waarop je een kopie van jou site draait kun je controleren of het aan de applicatie, of aan de inrichting van de server ligt. Je hebt iig een stok om de hoster mee te slaan.

Ik zou eventueel de 'preview' omgeving kunnen laten zien, die werkt namelijk nog prima.

cyberjack77 schreef op donderdag 17 juli 2014 @ 15:57:
Memory probleem?

De regel if ( isset($plugin_page) ) { wordt namelijk eerder ook al gebruikt en daar levert het geen probleem op.

Dat zou goed kunnen, het stukje code doet niks raars. Een memory leak is zeker een mogelijkheid, misschien na een software update op de server ofzo.

HamuNaptra schreef op donderdag 17 juli 2014 @ 16:01:
Misschien een mislukte hackpoging op je WP installatie?

Probeer alleszins gewoon de originele bestanden eens terug te zetten.
Ik neem aan dat het nu belangrijker is om een werkende website te hebben, dan enkele uren/dagen te verliezen met de rootcause te zoeken.

Uiteraard heb ik WordPress opnieuw geupload, maar dat leverde niks op. Verder zijn er geen aanwijzingen te vinden, dat de website gehacked is. Lijkt sowieso niet gerelateerd aan het probleem dat nu speelt.

Solopher schreef op donderdag 17 juli 2014 @ 22:02:
Heb je toevallig je wp-config al bekeken? Laatst was een server waar een site opstaat die ik beheer slachtoffer worden van een hack.

In de wp-config kon ik helemaal naar rechts scrollen waar de nodige code was geïnjecteerd.

Uiteraard, om WP_DEBUG, op true te zetten. Niks bijzonders kunnen vinden en het anders instellen van WP_DEBUG maakte geen verschil.

kwaakvaak_v2 schreef op vrijdag 18 juli 2014 @ 09:32:
en een php error hoeft niet per saldo een 500 op te leveren, hangt er maar net vanaf hoe deze eruit valt. Op sommige hosts wil PHP soms onverklaarbaar er wel eens uit klappen met een segfault, en de komt niet in de apache log, niet in de php log maar wel in de messages of syslog terecht.

Ja precies, ik weet bijna zeker dat het een fout op serverniveau is. Iets waar ik in ieder geval niets aan kan doen. Een segfault is inderdaad naast en memory leak ook een typische mogelijkheid.

---

Inmiddels contactgegevens ontvangen en dus een ticket aangemaakt bij de hoster. We zullen zien!

[CyberJack]

TheNephilim schreef op vrijdag 18 juli 2014 @ 10:20:
[...]

Dat zou goed kunnen, het stukje code doet niks raars. Een memory leak is zeker een mogelijkheid, misschien na een software update op de server ofzo.

Ik bedoel niet zo zeer een memory leak, maar het zou kunnen dat het max geheugen wat een php process mag gebruiken te laag staat. Aangezien phpinfo uitgeschakeld is zou je dit moeten kunnen opvragen met ini_get("memory_limit"); (als deze ook niet uitgeschakeld is). 32MB is normaal voor alleen de admin en met wat plugins kan dit makkelijk oplopen tot 64MB.