PHP 5.3 ve sessions klasörü ile ilgili sorunlar

81

Yakın zamanda PHP 5.3'e yükselttim ve o zamandan beri Apache'nin (veya oturum dosyalarının temizleyicisi olabileceğini) oturumların depolandığı klasör için hiçbir izni olmadığını gösteren (ara sıra) hata mesajları alıyorum.
Bu rastgele gerçekleşir ve kesin adımlarla çoğaltılamaz, bu da oturum temizleyici olduğunu tahmin etmeme neden oldu.
Bu tür hatalarla ilgili tecrübesi olan var mı?

Hata mesajı ( session_start()hatta ateşlenen ):

ps_files_cleanup_dir: opendir (/ var / lib / php5) başarısız oldu: İzin reddedildi.

Oturum dizinindeki ls -ltr şunu verir:

drwx-wx-wt  2 root          root          4096 2010-05-25 12:39 php5

Bu dizinin içinde Apache'im olan www-data'ya ait oturum dosyalarını görüyorum ve uygulama iyi çalışıyor. Merak ediyorum, GC oturumu hangi kullanıcı altında çalışıyor?

php session

— Itay Moav -Malimovka
kaynak

Yaptım ama 5.3'te değil. Oturum kaydetme yoluna göre filtrelenen bir izin hatası olduğu ortaya çıktı. İzinleri kontrol ettiğinizi varsayıyorum?

— Jarrod Nettles

@Jarrod Görüyorum ki www-data bu klasörü okuyabilir ve yazabilir (şu anda herkes, kullanıcı, grup ve dünya için w & r var) başka bir şeyi kontrol etmeli miyim?

— Itay Moav -Malimovka

Bunun düzensiz olmasının nedenini tahmin ediyorum, hatanın oturum çöp toplayıcısı çalıştırıldığında meydana gelmesi, ki bence varsayılan olarak oturum başlatma başına% 1 çalışma şansı var. Oturumlarla ilgili olarak php.ini'de herhangi bir değişiklik yaptınız mı? Burada varsayılanın dışında ne var? Oturum klasörünün sahibini kontrol edin, bundan sonra .ini veya hataları görmeden kayboldum.

— Jarrod Nettles

Sahibi köktür, oturumlar www-data ile oluşturulur, herkesin bu klasöre erişimi vardır. İni ayarlarını tek tek inceleyeceğim, şüpheli bir şey arayacağım.

— Itay Moav -Malimovka

ps_files_cleanup_dir: opendir (/ var / lib / php5) başarısız oldu: İzin reddedildi (

— Itay Moav -Malimovka

121

Düzeltme: senin içinde php.inisetine session.gc_probabilityiçin0

Cevabı burada bulduğuma inandığım neden http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

Esasen, çöp toplama bazı sistemlerde (yani Ubuntu / Debian) cron işleri tarafından yapılacak şekilde ayarlanmıştır. Php-cli gibi bazı php ini çalıştırılabilir dosyaları da çöp toplama yapmaya çalışır ve bu da aldığınız hatayla sonuçlanır.

— Diwant Vaidya
kaynak

6

Ubuntu 10.04'te de bu sorunu yaşıyorum, ancak php.ini'yi kontrol ettikten sonra session.gc_probabilityzaten olarak ayarlandığını buldum 0.

— Jonathan

5

@Jonathan - Muhtemelen uygulamanızın değeri ayarladığını göreceksiniz.

— SynackSA

3

Ben ne zaman bu özel bir mevkiye özel php.ini dosyasını, oluştururken @SynackSA Garibi, bu kadar session.gc_probability1'e tetikleyiciler Bu oldu Php.ini dosyada hiçbir ayar vardır bile olursa olsun ! Ubuntu, Apache 2.2'de suphp çalıştırıyorum. Acaba bu bir tür hata mı? Her neyse, session.gc_probability = 0özel, siteye özgü php.ini dosyama eklemek sorunu çözüyor gibi görünüyor.

— Jonathan

2

— @Jonathan

2

Bu, oturum çöp toplama işlemini devre dışı bırakır. Seanslarınızı gerçekten temizleyen bir cron olup olmadığını kontrol etmek isteyebilirsiniz.

— 2016

23

Bu, Ubuntu sunucularında tipik bir hata gibi görünüyor (Lucid LTS kullanıyorum). / Var / lib / php5 dizininin varsayılan izinleri

drwx-wx-wt  2 root     root     4096 2011-11-04 02:09 php5

yani yazılabilir ancak web sunucusu tarafından okunamaz, sanırım bu hataları açıklıyor.

Ubuntu'nun cron ( /etc/cron.d/php5) aracılığıyla kendi çöp temizliği olduğundan , yukarıda Diwant Vaidya tarafından önerildiği gibi php'nin çöp toplamasını devre dışı bırakmak muhtemelen en iyisidir.

session.gc_probability = 0

PHP Kılavuzunun dediği gibi, aslında oturum klasörünün herkes tarafından okunabilir olmaması için bir neden var :

Bu seti / tmp (varsayılan) gibi herkes tarafından okunabilen bir dizine bırakırsanız, sunucudaki diğer kullanıcılar o dizindeki dosyaların listesini alarak oturumları ele geçirebilirler.

— Marie Fischer
kaynak

2

Şu anda kullandığım çözüm (ki bunun doğru olduğundan emin değilim), oturum klasörünün sahipliğini Apache kullanıcısına (benim durumumda www-verisi) vermektir.

— Itay Moav -Malimovka
kaynak

2

Marie'nin yukarıda bahsettiği gibi, bu herhangi bir üretim sunucusu için bir güvenlik sorunu oluşturabilir.

— Kzqai

2

Ben çoktan güvenlik sorunu paylaşılan sunucularında çoğunlukla, doğru çözümü hayata :-) Ama var

— Itay Moav -Malimovka

1

@pike Oturum temizliği, CRON aracılığıyla php cli tarafından gerçekleştiriliyor

— Itay Moav -Malimovka

1

Bu sorun beni bir süredir rahatsız ediyor. Değeri php.ini'de önerildiği gibi değiştirdim ve sorun devam etti. İndex.php ve private / Zend / session.php dosyamda aynı yapılandırma değerini buldum. Bu nedenle, sorun devam ederse biraz daha derinlemesine bakmaya değer. Umarım bu birisi için yararlıdır.

— ChrisFNZ
kaynak