[Starweb]

Vi har drabbats av ett besynnerligt problem med session-cookies i php4 på en antal av våra servrar.

Den enda skillnaden är att vi nyligen har höjt session timeout-tiden till 24 timmar, och startat om apache.
Det som skedde då var att /tmp-katalogen snabbt fylldes med sessioner och tills den nått sin gräns och skrev då ut ett felmeddelande.

- Vi har därefter ändrat tillbaka session timeout-tiden till 90 minuter som det var tidigare, och startat om servrarna.

Trots att vi alltså justerat tillbaka allt såsom det var innan vi ändrade session timeout-tiden så har vi nu problem med sessionerna(!)


Vi tror att problemet uppstår när den ska skriva eller läsa in sessionen igen.
Webbläsaren hänger sig totalt, men inte alltid, utan endast om man tex provar att spara sina inställningar på en webbsida med tex ett formulär flera gånger. Ibland den 3:e gången, ibland den 10nde, ibland den 14nde osv. Det finns alltså inget mönster när servern bestämmer sig för att inte skriva/läsa sessionen.

Om man inte väljer att starta om webbläsaren så upphör låsningen efter ca 3-8 minuter och man kan åter använda applikationen igen. Vi gissar att servern då har fått tillräckligt med utrymme i /tmp-katalogen för att skapa en ny session.
(Observera att den inte ger några felmeddelanden i webbläsaren)

OM man klickar på att spara formuläret igen då, så sker lika ofta låsning igen.

Vad som sker på själva sidan där problemet uppstår är i princip två saker:
* Det sker dels en skrivning till databasen med all formulärdata från sidan och dels laddas sidan med formuläret om.
* När sidan har låsts så kan man gå in i tabellen i databasen och se att ändrade värden kommit in. Efter att den skrivit värdena till databasen så tömmer den sessionen och lagrar in nya värdena i sessionen på nytt. Inget avancerat alltså.

- Vi har provat flera php mjukvaror vi kört på dessa servrarna i flera år, och problemet uppstår i samtliga där lite större sessioner är inblandade. (Om man bara lagrar LITE information i sessionen så verkar inte problemet uppstå....)


=> Till saken hör att problemet gäller samtliga servrar där vi ändrat session-timeout tiden på sistone, och därefter ändrat tillbaka.

Session-kakorna kan bli rätt stora, uppåt 40kb, men som sagt detta har aldrig varit ett problem tidigare.
Vi har även bytt brandvägg i samband med session-timeout ändringen, men att den skulle påverka något verkar mycket osannolikt.

Serverarna är freebsd-servrar och kör bland annat apache, php4 samt mysql.
Dessa har inte ändrats i övrigt och allt fungerade bra innan sessiontidsförändringen och brandväggsbytet.


Har någon här upplevt samma problem efter ändring av sessionerna i php4 på freebsd, eller vet något annat som kan tänkas ha samma orsak?

Tacksam för all hjälp!

[SimonP]

Vad står det i Apache loggen?
PHP loggen?

[coredev]

Har ni prövat att manuellt tömma sessions-katalogen?

# rm -f

[TobiasEklund]

Ursprungligen postat av coredev

Har ni prövat att manuellt tömma sessions-katalogen?

# rm -f

Ja, sessionerna har tömts ut manuellt. Inget resultat.
På en annan server som är totalt obelastad och samma förändringar gjorts på
kan jag däremot inte alls få fram felet på.

Ursprungligen postat av SimonP

Vad står det i Apache loggen?
PHP loggen?

Vi har inte tillgång till loggarna för apache och php för tillfället.

Vad som kan tilläggas är att vi i samband med ny brandvägg också fått dubbla ISP:er.
Så ytterligare en fråga är om dubbla internetleverantörer kan ha med saken att göra.

En trace route från två olika platser ger olika vägar till servrarna men samma fel
kan upplevas oavsett vilken väg trafiken tar.

[Magnus_A]

Stänger ni och skriver sessionerna med session_write_close() i scriptet?

[danjel]

40 kb, typ 10 sidor text motsvarande?
Antar att sessions cookien inte expirar och har kvar samma sessions id?

Kan du posta koden..?

[Starweb]

Hej igen,

Nu har vi lite mer info.


* När man VPNar in till Binero (de hostar alla våra servrar) så uppstår aldrig felen.
- Det talar för att felet ligger i brandväggen.

* På en av servrarna har nu tekniker kompilerat om php + installerat om apache på, och felet kvarstår.
- Det talar för att felet ligger i brandväggen.

* Efter att vi har talat med en nätverksspecialist som direkt trodde att det berodde på hårdvaran, så kom han med förslaget att det kunde ha och göra med att switchen inte var kompatibel med den brandväggen. Vi har därför provat andra switchar, och även bytat uplink-sladd, tom kopplat in oss direkt på en av Bineros switchar, men felet kvarstår.
- Det talar emot att felet ligger i brandväggen.

* Alla servrarna har exakt samma inställningar (samma profil) i brandväggen, och då vi även blivit omkopplade med en server till Bineros switchar så bör vi därmed även ha provat deras brandväggsinställningar.
- Det talar emot att felet ligger i brandväggen.

* Brandväggsloggen skriver bara ut vilka paket den skickar, samt om den blockerar något. Enligt tekniker så blockerar den inget relevant som skulle kunna ha med detta problemet att göra.

* Apache/php loggarna ger oss heller inget att gå på. Den gör en POST av formuläret, sedan får man vänta i 1-10 minuter, varpå formuläret laddas/sparas. Det enda som då står i apache är att en POST görs, sedan 1-10 minuter senare så görs ett par GET...

* Observera att vi kör localhost med mysql på en del av dessa servrar, och separata webb/db servrar på andra, det kan alltså inte ha med mysql dns-uppslag att göra.

* Binero kan inte backa tillbaka nätet till det gamla subnätet och testa på nytt med deras gamla brandvägg, även om vi skickar de en annan brandvägg. Det skulle påverka alla deras befintliga kunder.


Som sagt, vi börjar köra slut på alternativ, och problemet uppstår som sagt inte VARJE gång man skickar ett formulär eller dylikt, utan ibland den 1:a, ibland den 3:e, ibland den 7:e ibland den 10nde gången osv...


Vi har börjat prova med att dels minska sessionerna och dels med session_write_close().
Då verkar problemet uppenbara sig MER SÄLLAN, men det uppstår alltså fortfarande.



Problemet är att två saker ändrades samtidigt, dvs dels så ändrade de våra session-timeout tider, och dels bytade de brandvägg. Sessionerna har de nu ändrat tillbaka, startat om servrarna, omkompilerat php+apache, men det kvarstår. Därmed kan vi/de inte utesluta det ena eller det andra problemet.

Någon som har fler idéer?

[danjel]

posta kod, det underlättar..