[PHP?] Sessieproblemen

[xilent_xage]

Hoi,

Ik heb sinds vandaag een probleem waar ik redelijk wanhopig van wordt. De hele dag heb ik al lopen debuggen maar het probleem wordt daar voor mij alleen maar onbegrijpelijker door. Wellicht heeft het probleem niet direct met php te maken maar met linux of zelfs php, maar ik denk dat ik in dit forum de grootste kans op een oplossing heb.

De situatie

• Ik heb mijn eigen framework gebouwd.
• Ik heb 4 websites die allen van hetzelfde framework gebruik maken. Een site begint bij index.php waar een .ini ingeladen wordt, waarna het framework de rest doet.
• Ik laat al mijn output door php parsen, dus ook css/js/images etc
• Deze output wordt zoveel mogelijk en meerlaags lokaal gecached, iedere website heeft dus zn eigen cache.
• Alle sites draaien op dezelfde server.

Het probleem

• Sessies blijven niet behouden maar worden geheel of gedeeltelijk gereset.
• Er verschijnen heel soms foutmeldingen van php die niet terecht zijn. Het probleem zit vaak steeds in andere files, als ik ctrl-f5 (zonder iets te wijzigen) is de error weer opgelost of zit ie ergens anders. Het lijkt soms wel of bestanden niet goed door php worden ingelezen (vaak unexpected end ed)
• Dit probleem treedt bij 1 website op, de rest heeft nergens last van.
• Ik kan niet meer achterhalen wat ik deed waardoor het misging. Ik heb wel eens eerder last gehad van dit probleem, echter toen leek het vanzelf te zijn opgelost. Ik had ook wat dingen aangepast maar ik weet niet of het daaraan lag...

Troubleshoot

• Ik heb een testscriptje gemaakt waarin ik echo of de sessie bestaat, en steekproefsgewijs check ik of ie compleet is. Als ik dit scriptje ga zitten F5en dan is ie steeds om-en-om in orde. Dus iets als: OK -> Leeg -> OK -> Incompleet -> OK -> Leeg.....
• Als ik direct na de session_start() meet is alles in orde
• Als ik de HTML van de pagina niet output gaat alles ook ok, ook als ik andere data output (hello worlds ed)
• Als ik een klein stukje uit de HTML verwijder werkt alles ok. Als dit stukje erin zit dan gaat het weer mis. Zelfs als ik js uitschakel.
• De HTML die het probleem lijkt te veroorzaken is (volgens mij) hele normale html (valideert ook prima), al jaren in gebruik bij al mijn sites, nooit problemen mee gehad.

Analyse
Hoewel ik het bijna niet kan geloven lijkt het probleem in een stukje HTML te zitten. Als ik dat output (binnen normale XHTML1 strict) dan gaat het mis. Als ik dat verwijder dan werkt het testscript goed. Ik heb dit inmiddels 8x getest.

HTML:

                    <div id="login_image_holder"><img id="login_image" src="/icon_login.jpg" title="Beveiliging: Onbeveiligd" alt=""/></div>
                    <form id="normal_screen" action="/" method="post" enctype="multipart/form-data">
                        <fieldset>
                            <legend>Inloggen</legend>
                            <label for="username">Gebruikersnaam:</label>
                            <input type="text" id="username" name="username" size="10" maxlength="254" value="" />
                            <label for="password">Wachtwoord:</label>
                            <input type="password" id="password" name="password" size="10" value="" />
                            <span class="hidden" id="salt1_change"></span>
                            <span class="hidden" id="salt2_change"></span>
                        </fieldset>
                        <fieldset class="submit">
                            <input type="submit" class="inputSubmit" value="Inloggen" />
                            <input type="hidden" name="submit_login" value="true" />
                        </fieldset>
                    </form>
                    <form id="openid_screen" action="/" method="post" enctype="multipart/form-data" class="hidden">
                        <fieldset>
                            <legend>Inloggen met OpenID</legend>
                            <label for="openid_username"><img src="/themes/kiem/icons/openid_2.gif" />&nbsp;OpenID:</label>
                            <input type="text" id="openid_username" name="openid_username" size="10" maxlength="254" value="" />
                        </fieldset>
                        <fieldset class="submit">
                            <input type="submit" class="inputSubmit" value="Inloggen" />
                            <input type="hidden" name="submit_openid" value="true" />
                        </fieldset>
                    </form>

Of ik zie echt iets heel stoms over het hoofd (daar zit bij mij meestal het probleem) of dit zaakje stinkt. Iemand enig idee?

[DataGhost]

Wat is je serversoftware en -configuratie?
Wat zijn de precieze foutmeldingen en waarom zouden ze onterecht zijn?
Heb je hardware-oorzaken al uitgesloten?
Hoe output je dat laatste stuk HTML precies? Ik kan me nauwelijks voorstellen dat dat stuk an sich de oorzaak zou kunnen zijn.

[xilent_xage]

DataGhost schreef op zaterdag 12 februari 2011 @ 22:15:
Wat is je serversoftware en -configuratie?
Wat zijn de precieze foutmeldingen en waarom zouden ze onterecht zijn?
Heb je hardware-oorzaken al uitgesloten?
Hoe output je dat laatste stuk HTML precies? Ik kan me nauwelijks voorstellen dat dat stuk an sich de oorzaak zou kunnen zijn.

Ha een reactie! Waarvoor dank. Zit inmiddels met een glazige blik te F5en hier

1. Ubuntu, redelijk standaard LAMP allemaal. Draait op een managed dedicated server.
2. Er staat bijv " Unexpected private in file x line y". In het betreffende bestand x staat op regel y helemaal geen private. Dat soort vage shit.
3. Nee, anders dan dat er geen wijzigingen aan de server hard- en software zijn doorgevoerd. Mijn gevoel neigt een beetje naar een probleem met het lezen/schrijven/locken van bestanden in de cache dir, maar ik weet niet zo goed hoe ik zoiets moet troubleshooten. Maar omdat ik uitkom bij dat ene stomme stukje html ben ik daar maar niet op doorgegaan.
4. Ik gebruik een eigen output-object die netjes de headers output en daarna
   
   PHP:
   

                   ini_set('zlib.output_compression_level', $this->settings['compression_level']);
                   ob_start("ob_gzhandler");
   
                   #output
                   print_r($this->pagecontent);
                   ob_flush();

[Voor 5% gewijzigd door xilent_xage op 12-02-2011 22:28]

[xilent_xage]

Ok, nog even excuus maken. Na een nacht lang doorploeteren bleek het toch zoals altijd 'the obvious' te zijn: de user zat aan zijn diskquotum, waardoor caches niet/gedeeltelijk werden weggeschreven. Door het weglaten van het 'verdachte' stukje html paste de output net in de cache op de disk.

[CH4OS]

xilent_xage schreef op zaterdag 12 februari 2011 @ 22:25:
• Er staat bijv " Unexpected private in file x line y". In het betreffende bestand x staat op regel y helemaal geen private. Dat soort vage shit.

Als je files include, dan worden die regels opgeteld als het ware. Controleer nog eens, als je dan gaat tellen als je wil?

xilent_xage schreef op zondag 13 februari 2011 @ 10:22:
Ok, nog even excuus maken. Na een nacht lang doorploeteren bleek het toch zoals altijd 'the obvious' te zijn: de user zat aan zijn diskquotum, waardoor caches niet/gedeeltelijk werden weggeschreven. Door het weglaten van het 'verdachte' stukje html paste de output net in de cache op de disk.

Heb je dan al eens gedacht aan GZIP compressie? Scheelt ook uiteindelijk dataverkeer...

Waarom je zelfs de JS en CSS parsed is mij een raadsel, op zich heb je dat niet nodig en zorgt het alleen maar voor overhead (en dus vertraging).

[Voor 25% gewijzigd door CH4OS op 13-02-2011 10:41]

[xilent_xage]

Heb je dan al eens gedacht aan GZIP compressie? Scheelt ook uiteindelijk dataverkeer...

doe ik

Waarom je zelfs de JS en CSS parsed is mij een raadsel, op zich heb je dat niet nodig en zorgt het alleen maar voor overhead (en dus vertraging).

ik stel zelf de css en js samen uit bestaande scripts. deze worden dan geaggregeerd tot 1 bestand, waarna ze geoptimaliseerd worden (valideren, ontdubbelen, minificeren). Bovendien worden de bestanden geparsed met Smarty, dus je kunt variabele scripts en stylesheets gebruiken... handig!

Qua overhead valt het reuze mee, de gegenereerde bestanden worden gecached, waarna je nauwelijks enige overhead hebt...