[PHP/SVN] PHP stopt met parsen zonder error

[storeman]

Ik heb een server welke ik gebruik als testomgeving (Zend Server), database server (postgres) en versie beheer server (SVN). Lokaal ontwikkel ik en doe zo nu en dan een commit. Op de server staat een test-omgeving waarin getest kan worden onder linux (Ubuntu 9.10). Ik wil niet iedere keer alle bestanden via FTP uploaden, dus heb een bash gemaakt, welke een export kan doen vanuit SVN.

Echter op willekeurige momenten treedt er een fout op in de applicatie welke niet te herleiden is. Het resultaat is een wit scherm met de volgende headers:

200 OK

Een andere pagina uit de applicatie werkt prima, en geeft volledige headers terug. Ik ben al een tijd aan het zoeken naar het probleem, maar ik kan er geen structurele oplossing voor vinden. Het blijkt wel dat als ik ga kijken wat er werkt dmv die() op verschillende plekken, het probleem ineens over is. (Bewerk het bestand remote via nano).

Wat ik al heb geprobeerd:
- Alvorens een update worden alle mappen verplaatst naar een backup map (aantal configs moeten later terug)
- Rechten staan goed, www-data is owner (user/group) en op 0755, dit werkt prima.
- In SVN heb ik een meta-tag toe gevoegd voor EOL-style:native

Bij andere fouten komt er iets in de applicatie of php-log te staan, maar dit sterft gewoon een té stille dood. Iemand een suggestie wat ik kan proberen?

[X-Lars]

Heb je al gekeken naar de config van met name PHP en DB? Ik doel bijv. op error_reporting, memory_limit, dat soort zaken. Er moet natuurlijk een verschil zijn tussen dev en test.

Edit: als je telkens een export doet, blijven er wellicht files/folders achter die er niet meer zouden moeten zijn?

[Voor 25% gewijzigd door X-Lars op 05-10-2010 17:21]

[ZaZ]

X-Lars schreef op dinsdag 05 oktober 2010 @ 17:20:
Edit: als je telkens een export doet, blijven er wellicht files/folders achter die er niet meer zouden moeten zijn?

Daarvoor heb je een force commando.
Wat ik zelf in geautomatiseerde omgevingen altijd doe is een revert en checkout.
Vooral met grotere projecten veel minder zwaar.

[storeman]

@X-Lars:
Het zit 'm niet in de config. Als ik een bestand wijzig door er een die(); in te zetten, op te slaan, een request te doen en de wijziging weer ongedaan maak, dan doet hij het WEL! Heel bijzonder. Ik heb dus het idee dat er een bitje verkeerd staat binnen het bestand. Als ik de export nogmaals doe, is het probleem vaak ergens anders in de applicatie.

In de config kan het niet zitten, want dan is er altijd sprake van een error érgens. Ik gebruik dezelfde DB ook op mijn dev bak (remote).

Voordat ik een export doe, verplaats ik de map en maak ik een nieuwe aan, dus er kan geen 'oude' zooi blijven hangen.

@ZaZ:
Daar zat ik ook aan te denken, echter vind ik het niet logisch om een Working Copy te hebben in de testomgeving. Met name omdat ik dan daar ook een db krijg met allemaal .svn mappen.

[X-Lars]

storeman schreef op dinsdag 05 oktober 2010 @ 19:11:
@X-Lars:
Het zit 'm niet in de config. Als ik een bestand wijzig door er een die(); in te zetten, op te slaan, een request te doen en de wijziging weer ongedaan maak, dan doet hij het WEL! Heel bijzonder. Ik heb dus het idee dat er een bitje verkeerd staat binnen het bestand. Als ik de export nogmaals doe, is het probleem vaak ergens anders in de applicatie.

In de config kan het niet zitten, want dan is er altijd sprake van een error érgens. Ik gebruik dezelfde DB ook op mijn dev bak (remote).

Je kan met o.a. error_reporting wellicht wel errors loggen. Het lijkt me sowieso een goed idee om de phpinfo() van beide omgevingen eens te vergelijken.

Voordat ik een export doe, verplaats ik de map en maak ik een nieuwe aan, dus er kan geen 'oude' zooi blijven hangen.

Wellicht handig om dit met bijv. een Ant build script te doen. Je kan ook iets als rsync gebruiken om dit te automatiseren.

@ZaZ:
Daar zat ik ook aan te denken, echter vind ik het niet logisch om een Working Copy te hebben in de testomgeving. Met name omdat ik dan daar ook een db krijg met allemaal .svn mappen.

Dat is inderdaad zeker niet de bedoeling. Je kan ook dit automatiseren door je db schema en data te dumpen op dev en te importeren op test (Ant).

Aangezien je svn gebruikt, is het wellicht een idee om gewoon eens een aantal revisies terug te gaan en die te deployen.

[Gomez12]

Hoe groot/snel is je repository? Is het niet gewoon SVN die nog bezig is met het exporteren waardoor er bepaalde bestanden niet staan, of net herschreven worden?

Ter info : wij hebben repositories staan van enkele Gigs groot, daar kan een commit/export wel enkele minuten duren voordat je op F5 in je browser kan duwen.

[storeman]

Hoewel ik het erg op prijs stel dat jullie me proberen te helpen, heb ik het idee dat de essentie van het geheel niet helemaal doorkomt. Als ik het bestand dat de fout geeft wijzig en opsla (als is het maar een extra spatie), dan werkt het wél weer!

Je zou denken dat error reporting errors zou laten zien, maar dat is dus niet zo. Error Reporting staat op E_ALL en display errors staat On evenals display_startup_errors, dus dat kan het niet zijn.

@X-Lars: Ik heb een bash bestand welke die handelingen uitvoert, vanuit php doe ik een exec() zodat de goede user dit doet en alle bestanden door www-data zijn te benaderen. Je oplossingen met rsync en ant lijken interessant, maar ik denk niet dat dit de essentie van mijn probleem is.

@Gomez12: Mijn repo is niet zo groot. SVN is zeker niet bezig, omdat ik in de webinterface kan zien dat de export klaar is dmv exec();

[Voutloos]

storeman schreef op dinsdag 05 oktober 2010 @ 21:28:
Als ik het bestand dat de fout geeft wijzig en opsla (als is het maar een extra spatie), dan werkt het wél weer!

Om uit te sluiten dat de editor iets fixed: voldoet een touch ook?

Heb je iets als een opcode cache draaien? Of een funky nfs config?

[storeman]

hmm... lijkt dat dat verschil maakt. Ik heb net een poging gedaan een "wit scherm" te fixen, heb heel wat bestanden getouched, maar uiteindelijk lijkt het wel te hebben geholpen. Probleem gevonden dus! Nu nog een oplossing...

Er draait inderdaad een opcode cache (Zend Optimizer+), daarnaast heb ik APC draaien. Eens verder experimenteren.

Tips zijn welkom

[Voutloos]

Deploy naar een nieuwe locatie en gooi in 1x een symlinkje om. Dan heb je geen problemen met caching meer, en bovendien ook niet tijdelijk een halve installatie.

[storeman]

klinkt als een plan !

[Voor 4% gewijzigd door storeman op 05-10-2010 23:00]

[storeman]

Ik krijg het niet voor elkaar om een symbolic links werkend te krijgen. Het resultaat blijkt alleen maar meer witte schermen zonder errors. Ik heb m'n update script uitgebreid met 'apc_clear_cache', dit lijkt te schelen, maar kan ik nog niet met 100% zekerheid zeggen.

[Cartman!]

De combinatie APC en Zend Optimizer kan nogal problemen opleveren of is dat tegenwoordig verholpen? Misschien ook nog PHP z'n eigen filesystem cache uitschakelen met clearstatcache(); ?

[Voutloos]

En toch moet er ook iets in de logs verschijnen... Check dat nog eens...