Re: Czy php.cgi korzysta z php-cgi.ini?
On Tuesday January 26 2010 22:45:12 Arkadiusz Rdest wrote: > Remigiusz 'Enleth' Marcinkiewicz pisze: > > Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie > > jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i > > działa dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale > > czasu nie mam żeby dopracować i opisać... > > poproszę na priv'a albo linka do sciagniecia. > z checia popatrze i pomysle nad zmianami u siebie. > > teraz mam okolo 4k kont. php odpalane przez mod_fastcgid w apachu. > ale jest problem z reloadami konfiguracji. zwykle w pamieci wisi 2-3k > procesow PHP, no i przy relaodzie apacha (przez graceful np. w celu > dodania nowych vhostow) load skacze bardzo konkretnie (czasem do > 400-500, bo musi ubic te 3k procesow i wystartowac od nowa. > > [...] Od razu mówię, że skrypt testowany był na maksymalnie kilkudziesięciu procesach fcgi, więcej mi potrzebne nie jest. Aktualnie działa na - być może śmiesznych dla niektorych - czterech. Dla mnie akurat to, że działają one stale i niezależnie od serwera HTTP (którym u mnie jest lighttpd, więc w sprawach związanych z konfiguracją apacha nie pomogę; konfigi lighttpd można w pewnym stopniu skryptować substytucją zmiennych np. w ścieżkach socketów) jest pożądane i celowe, choćby dlatego, że cache akceleratora dla danego vhosta może bardzo długo wisieć w pamięci. Różnica w prędkości ładowania stron zaraz po restarcie procesu fcgi, zanim się cache wypełni często używanymi plikami, nie jest może wyraźnie widoczna, ale jest mierzalna. Za to restarty jakiegokolwiek pojedyńczego procesu, czy to fcgi czy lighttpd, są natychmiastowe i nie wpływają na całą resztę, można sobie do woli grzebać w konfiguracji i testować dowolny element. Skrypt gdzieś wrzucę jakoś pod wieczór. Aha, fcgi w trybie proces na vhost na usera, z oddzielną dla każdego konfigurajcą, jest używane na dość sporą skalę przez kilka dużych firm hostingowych, w tym bluehost i dreamhost. Co by nie mówić o uptime ich serwerów i jakości obsługi technicznej, fcgi im akurat wyszło i działa dobrze. Fakt, że na monstrach z 8 CPU i 32GB pamięci, ale organizacyjnie jakoś sobie z tym poradzili. > ja do przyspieszenia dzialania serwer mam reverse proxy (squid) z przodu > serwera . Sprawdza sie. Czy te accelratory dzialaj dobrze z > srodowisku multiuserowym fastcgi? trzeba je osobno dla kazdego vhosta > odpalac? czy wystarczy jakis jedna wspolna konfiguracja? Akceleratory PHP, po załadowaniu modułu w konfiguracji, działają całkowicie automatycznie jako element parsera i, w uproszczeniu mówiąc, przechowują skrypty w pamięci procesu, w postaci wygenerowanej przez parser i wykonywalnej bezpośrednio w maszynie wirtualnej Zend Engine oraz wykonują mniejszą lub większą optymalizację kodu i czasami oferują jakieś API do shm (IMHO memcache lepszy). W środowisku multiuserowym/multiprocesowym działa to dobrze, jeśli przyjąć chyba dość sensowne założenie, że userzy nie korzystają z tych samych plików PHP. Wyjątkiem może być jakaś tam systemowa instalacja ZF, ale jakoś mi się nie chce wierzyć, że takie globalne kopie frameworków i bibliotek PHP są powszechnie i konsekwentnie używane, więc problem wielki raczej nie jest. A shm dzielone między userami w ogóle nie powinno mieć miejsca. Generalnie, można powiedzieć że akceleratory przerzucają część obciążenia z I/O dysków i CPU na pamięć, więc jeśli serwer ma dużo wolnej pamięci a zatyka się na procesorach podczas wykonywania skryptów, jakiś akcelerator może znacząco poprawić sytuację. Jaki? Tego w sumie nie powie żaden benchmark poza tym zrobionym we własnym zakresie, bo różny kod może się różnie optymalizować konkretnymi algorytmami. -- Remigiusz "Enleth" Marcinkiewicz, enl...@enleth.com WWW http://enleth.com http://heroes.net.pl JID enl...@jabster.pl signature.asc Description: This is a digitally signed message part. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: CPU i %steal
Dnia 2010-01-24, nie o godzinie 21:49 +0100, Łukasz Jagiełło pisze: > To jak widać mam wyraźne zmiany %steal. W jaki sposób pobierać %steal > tak żeby faktycznie notować te zmiany, a nie praktycznie stałą > wartość, bo coś mi się wydaje, że ma ona mało wspólnego z > rzeczywistością. może sadf? -- Paweł Kwiatkowski e-mail/jid: qwiat(at)pld-linux(dot)org ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
Remigiusz 'Enleth' Marcinkiewicz pisze: > Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie > jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i działa > dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale czasu nie > mam żeby dopracować i opisać... poproszę na priv'a albo linka do sciagniecia. z checia popatrze i pomysle nad zmianami u siebie. teraz mam okolo 4k kont. php odpalane przez mod_fastcgid w apachu. ale jest problem z reloadami konfiguracji. zwykle w pamieci wisi 2-3k procesow PHP, no i przy relaodzie apacha (przez graceful np. w celu dodania nowych vhostow) load skacze bardzo konkretnie (czasem do 400-500, bo musi ubic te 3k procesow i wystartowac od nowa. szukam jakiegos innego rozwiazania jak by to zrobic koszernie. Nie wiem cy mi starczy pamieci zeby caly czas trzymac 4k parserow PHP w pamieci dla kazdego konta osobny (tu sie przyda twoj skrypt), bo jednak mod_fastcgi ma ta zalete ze spawn'uje je "on demand". jak potem wyglada konfiuracja w apachu? w kazdym vhoscie trzeba podac zeby odwolywal sie do konkretnego socketa? Albo moze napisz jak to masz u siebie rozwiazane. Moze na podstawie innego rozwiazania cos dla siebie wymysle. :) A mzoe wymyslil juz ktos, jak przy fastcgi trzymac konfiguracje vhostow w bazie danych, zeby apache sobie do niej na biezaco siegal? chodzi mi o cos w stylu vhostow na mod_rewrite, zeby przy dodaniu nowego vhosta nie trzeba bylo reloadowac apacha, ale zeby to dzialalo z fastcgi. bo googlalem długo ale nic nie znalazlem. >> Do tego nie działa z APC, >> który daje takiego kopa że niejeden serwer uratował... > > eAccelerator i xcache działają. Ten pierwszy w moich (bardzo nienaukowych i > nieudokumentowanych) testach był pod fcgi szybszy. Jeśli nie potrzebujesz > jakiejś konkretnej funkcjonalności którą ma tylko APC, może jeden z tych się > nada? ja do przyspieszenia dzialania serwer mam reverse proxy (squid) z przodu serwera . Sprawdza sie. Czy te accelratory dzialaj dobrze z srodowisku multiuserowym fastcgi? trzeba je osobno dla kazdego vhosta odpalac? czy wystarczy jakis jedna wspolna konfiguracja? -- Rdest Arkadiusz ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tue, 26 Jan 2010, Remigiusz 'Enleth' Marcinkiewicz wrote: On Tuesday January 26 2010 18:44:25 Jacek Osiecki wrote: On Tue, 26 Jan 2010, Arkadiusz Rdest wrote: Jacek Osiecki wrote: On Tue, 26 Jan 2010, Marcin Kurzyna wrote: Hmm, sprawdziłem php.cgi -i - i pokazało że używa /etc/php/php-cgi-fcgi.ini Dlaczego? Owszem, fcgi mam zainstalowane (za chwilę je usunę bo na nic się nie przyda chyba) a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy model odpalania prpocesów PHP. Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego zestawu fcgi+suphp miałem już serdecznie dosyć. Po prostu odpalać procesy na koncie usera którego prawa mają mieć wykonywane skrypty? Do tego żadnego sucrapa nie trzeba, wystarczy spawn-fcgi i skrypt startowy przystosowany do pracy z wieloma instancjami usługi. Jako bonus Nie wiem, próbowałem wielu różnych kombinacji i za każdym razem albo nie działało zgłaszając (lub nie) dziwaczne błędy z których nie dało się niczego wywnioskować, ewentualnie działało ale nie do końca (losowe "permission denied" lub diabli-wiedzą-czemu próba dostępu do innego katalogu niż trzeba). dostaniesz niewrażliwość serwera HTTP i procesów PHP innych userów na złamanie zabezpieczeń, zwis lub restart pojedyńczej instancji, możliwość podania całkowicie innej konfiguracji albo nawet wersji PHP na konkretny vhost, a jakby pokombinować, powinno być możliwe nawet prawdziwe chrootowanie PHP np. na ~/public_html/ usera. Ja się po prostu poddałem :) Nawet głupiego wykonywania z prawami usera nie mogłem wyegzekwować, a o chrootowaniu to nawet nie próbowałem marzyć :( Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i działa dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale czasu nie mam żeby dopracować i opisać... Udostępnij, może w końcu zrozumiem co właściwie należy ustawić w tym fcgi :) Mnie przerosły pliki konfiguracyjne, w których wszystko trzeba było ustawiać na czuja i najlepiej po kilka razy (w php.ini, w definicji virtualhosta, w osobnym .conf dla apache'a itd. Do tego nie działa z APC, który daje takiego kopa że niejeden serwer uratował... eAccelerator i xcache działają. Ten pierwszy w moich (bardzo nienaukowych i nieudokumentowanych) testach był pod fcgi szybszy. Jeśli nie potrzebujesz jakiejś konkretnej funkcjonalności którą ma tylko APC, może jeden z tych się nada? Ja jestem prosty człek, chcę mieć działający system. Przy fcgi kilka dni walki spełzło na niczym, a APC ma bardzo miłą zaletę: instalujesz i działa. Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale nawet o tym nie myślałem widząc jasny opis że php-cgi.ini jest includowane przy php.cgi :) Odpalanie php.cgi z crona naprawdę ci działa? CGI to nie synonim dla CLI, programy działające jako CGI oczekują konkretnych danych od serwera HTTP w zmiennych środowiskowych, zwracają wyjście z (częściowymi) nagłówkami HTTP i generalnie zakładają, że odpalić je mógł tylko serwer HTTP i nic innego. Jeśli działa, to chyba bardziej z przypadku niż zamierzeń autorów PHP... No bez przesady - to że wyrzuci nagłówki to żaden problem. Nie widzę powodów (poza estetycznymi), dla których php.cgi miałoby nie działać. Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tue, 26 Jan 2010, Marcin Kurzyna wrote: On Tuesday 26 January 2010 18:44:25 Jacek Osiecki wrote: a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy model odpalania prpocesów PHP. Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego zestawu fcgi+suphp miałem już serdecznie dosyć. Do tego nie działa z APC, który daje takiego kopa że niejeden serwer uratował... Szczerze mówiąc to ja tam nie wiem jaki problem jest z APC - SOA#1 ;-) Jak również z odpaleniem fcgi+suexec. Jakoś ile razy próbowałem cokolwiek z tym zrobić to APC w zasadzie nie było wykorzystywane... Teraz serwer jest już uruchomiony i żadne rewolucje nie wchodzą w grę, więc nawet nie odtworzę jakie dokładnie problemy były :) Jeśli natomiast uwzględniasz bezpieczeństwo to tylko via fcgi bo to ci daje separację dostępu do danych w APC. Przy mod_php kiedy cache jest *jeden* nie ma większego problemu z odczytaniem i zmienieniem danych innego vhosta ;-) Jakieś szczegóły? Bo nie znalazłem żadnych alertów o krytycznych bugach w APC - na secunia w zasadzie jest tylko jedno zgłoszenie, dotyczące buffer overflow... Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale Do tego to zdecydowanie php.cli OK - choć właśnie nie wiem czemu nie przekazał parametrów. Ale to sprawdzę jutro ;) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tuesday January 26 2010 18:44:25 Jacek Osiecki wrote: > On Tue, 26 Jan 2010, Arkadiusz Rdest wrote: > > Jacek Osiecki wrote: > >> On Tue, 26 Jan 2010, Marcin Kurzyna wrote: > >> Hmm, sprawdziłem php.cgi -i - i pokazało że używa > >> /etc/php/php-cgi-fcgi.ini Dlaczego? Owszem, fcgi mam zainstalowane (za > >> chwilę je usunę bo na nic się nie przyda chyba) > > > > a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy > > model odpalania prpocesów PHP. > > Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie > nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to > jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego > zestawu fcgi+suphp miałem już serdecznie dosyć. Po prostu odpalać procesy na koncie usera którego prawa mają mieć wykonywane skrypty? Do tego żadnego sucrapa nie trzeba, wystarczy spawn-fcgi i skrypt startowy przystosowany do pracy z wieloma instancjami usługi. Jako bonus dostaniesz niewrażliwość serwera HTTP i procesów PHP innych userów na złamanie zabezpieczeń, zwis lub restart pojedyńczej instancji, możliwość podania całkowicie innej konfiguracji albo nawet wersji PHP na konkretny vhost, a jakby pokombinować, powinno być możliwe nawet prawdziwe chrootowanie PHP np. na ~/public_html/ usera. Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i działa dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale czasu nie mam żeby dopracować i opisać... >Do tego nie działa z APC, > który daje takiego kopa że niejeden serwer uratował... eAccelerator i xcache działają. Ten pierwszy w moich (bardzo nienaukowych i nieudokumentowanych) testach był pod fcgi szybszy. Jeśli nie potrzebujesz jakiejś konkretnej funkcjonalności którą ma tylko APC, może jeden z tych się nada? >Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy >z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale nawet >o tym nie myślałem widząc jasny opis że php-cgi.ini jest includowane przy >php.cgi :) Odpalanie php.cgi z crona naprawdę ci działa? CGI to nie synonim dla CLI, programy działające jako CGI oczekują konkretnych danych od serwera HTTP w zmiennych środowiskowych, zwracają wyjście z (częściowymi) nagłówkami HTTP i generalnie zakładają, że odpalić je mógł tylko serwer HTTP i nic innego. Jeśli działa, to chyba bardziej z przypadku niż zamierzeń autorów PHP... -- Remigiusz "Enleth" Marcinkiewicz, enl...@enleth.com WWW http://enleth.com http://heroes.net.pl JID enl...@jabster.pl signature.asc Description: This is a digitally signed message part. ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tuesday 26 January 2010 18:44:25 Jacek Osiecki wrote: > > a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy > > model odpalania prpocesów PHP. > > Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie > nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to > jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego > zestawu fcgi+suphp miałem już serdecznie dosyć. Do tego nie działa z APC, > który daje takiego kopa że niejeden serwer uratował... Szczerze mówiąc to ja tam nie wiem jaki problem jest z APC - SOA#1 ;-) Jak również z odpaleniem fcgi+suexec. Oczywiście z dokładnością do rozumienia co to robi i jak działa, tj. pamięć współdzielona będzie w ramach procesu fcgi, a nie wszystkich działających procesów fcgi. Ale jak to Rasmus na grupie PHP ostatnio powiedział - problem i tak zazwyczaj nie jest z dostępnością pamięci, a z podziałem czasu procesora. Jeśli natomiast uwzględniasz bezpieczeństwo to tylko via fcgi bo to ci daje separację dostępu do danych w APC. Przy mod_php kiedy cache jest *jeden* nie ma większego problemu z odczytaniem i zmienieniem danych innego vhosta ;-) > Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy > z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale Do tego to zdecydowanie php.cli > >> ale czemu .cgi nie bierze php-cgi.ini tylko właśnie > >> php-cgi-fcgi.ini? Prawdopodobnie zły argument przy kompilacji. Hack rozróżniający cgi od fcgi to nasze PLDowe cudo, którego notabene można by sie do końca pozbyć (w 5.3 na HEAD to robiłem). Normalnie w php cgi===fcgi jeśli chodzi o binarkę. > > jesli chesz odpalac z konsoli to od tego jest php.cli (zreszta > > /usr/bin/php jest symnlinkiem do tej wlasnie binarki) a nie php.cgi na HEAD - w 5.2 afaik jest jeszcze oddzielną binarką (chyba że ktoś portował?) > Tylko coś nie bardzo chciało przyjąć parametry przekazywane z linii > poleceń... ale jeszcze sprawdzę. zapoznaj się z http://pl.php.net/manual/en/ini.core.php#ini.register-argc-argv może pomoże ;-) pozdrawiam mk ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tue, 26 Jan 2010, Arkadiusz Rdest wrote: Jacek Osiecki wrote: On Tue, 26 Jan 2010, Marcin Kurzyna wrote: Hmm, sprawdziłem php.cgi -i - i pokazało że używa /etc/php/php-cgi-fcgi.ini Dlaczego? Owszem, fcgi mam zainstalowane (za chwilę je usunę bo na nic się nie przyda chyba) a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy model odpalania prpocesów PHP. Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego zestawu fcgi+suphp miałem już serdecznie dosyć. Do tego nie działa z APC, który daje takiego kopa że niejeden serwer uratował... jak w koncu chcesz odpalac to PHP? jako mod_php, jako CGI, czy jako FastCGI? Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale nawet o tym nie myślałem widząc jasny opis że php-cgi.ini jest includowane przy php.cgi :) Odpalanie przez mod_php nieco "zabezpieczyłem" w sposób już tu opisywany - czyli katalogi ze stronami klientów są typu: /home/www/tajny_hash_na_podstawie_czegos_oraz_client_id/client_name/www/stronka Dodatkowo każdy virtualhost obwarowany odpowiednimi dyrektywami typu php_openbasedir (tak, teoretycznie można obejść ale symlink też zablokowany) i zablokowanymi podstawowymi funkcjami które mogłyby posłużyć do zaglądania tam gdzie nie wolno... I bez wielkich czarów jest w miarę OK. ale czemu .cgi nie bierze php-cgi.ini tylko właśnie php-cgi-fcgi.ini? a tego to nie wiem. uzywam php.fcgi jesli chesz odpalac z konsoli to od tego jest php.cli (zreszta /usr/bin/php jest symnlinkiem do tej wlasnie binarki) a nie php.cgi Tylko coś nie bardzo chciało przyjąć parametry przekazywane z linii poleceń... ale jeszcze sprawdzę. Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
Jacek Osiecki wrote: > On Tue, 26 Jan 2010, Marcin Kurzyna wrote: > Hmm, sprawdziłem php.cgi -i - i pokazało że używa /etc/php/php-cgi-fcgi.ini > Dlaczego? Owszem, fcgi mam zainstalowane (za chwilę je usunę bo na nic się > nie przyda chyba) a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy model odpalania prpocesów PHP. jak w koncu chcesz odpalac to PHP? jako mod_php, jako CGI, czy jako FastCGI? > ale czemu .cgi nie bierze php-cgi.ini tylko właśnie > php-cgi-fcgi.ini? a tego to nie wiem. uzywam php.fcgi jesli chesz odpalac z konsoli to od tego jest php.cli (zreszta /usr/bin/php jest symnlinkiem do tej wlasnie binarki) a nie php.cgi -- Arkadiusz Rdest ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tue, 26 Jan 2010, Marcin Kurzyna wrote: On Tuesday 26 January 2010 11:15:52 Jacek Osiecki wrote: Czy php-cgi.ini jest w ogóle olewane przez php.cgi? Wpisanie czegokolwiek do tego pliku - np. zmiana max_execution_time - nie daje absolutnie nic... Jak sprawdzam atime /etc/php/php*.ini, to jedyny który ma zmieniany atime to /etc/php/php.ini, zaś pozostałe - w szczególności php-cgi.ini... które PHP? 5.2 czy 5.3? W miarę aktualne - 5.2.11-13 a dwa - co ci phpinfo() mówi o pliku konfiguracyjnym? i nie jest tak że jeśli odpalasz via CGI to masz jakiś skrypt w którym masz konfig "z palca" podany jako parametr wywołania? ale to tylko szklana kula.. ostatnio coś ciemna. No taki już jestem że staram się wierzyć komentarzom ;) A w /etc/php/php.ini stoi jak byk: ; Please note, that in PLD installations /etc/php/php.ini file ; contains global settings for all SAPIs (cgi, cli, apache...), ; and after reading this file, SAPI-specific file (/etc/php/php-cgi.ini, ; /etc/php/php-cli.ini, /etc/php/php-apache.ini...) is INCLUDED ; (so you don't have to duplicate whole large file to override only ; few options) Więc albo to jest bzdura i należałoby usunąć z oficjalnego php.ini, albo coś jest zepsute w php.cgi. Hmm, sprawdziłem php.cgi -i - i pokazało że używa /etc/php/php-cgi-fcgi.ini Dlaczego? Owszem, fcgi mam zainstalowane (za chwilę je usunę bo na nic się nie przyda chyba) ale czemu .cgi nie bierze php-cgi.ini tylko właśnie php-cgi-fcgi.ini? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
On Tuesday 26 January 2010 11:15:52 Jacek Osiecki wrote: > Witam, > > Czy php-cgi.ini jest w ogóle olewane przez php.cgi? > Wpisanie czegokolwiek do tego pliku - np. zmiana max_execution_time - nie > daje absolutnie nic... Jak sprawdzam atime /etc/php/php*.ini, to jedyny > który ma zmieniany atime to /etc/php/php.ini, zaś pozostałe - w > szczególności php-cgi.ini... > > Dlaczego to nie działa? które PHP? 5.2 czy 5.3? a dwa - co ci phpinfo() mówi o pliku konfiguracyjnym? i nie jest tak że jeśli odpalasz via CGI to masz jakiś skrypt w którym masz konfig "z palca" podany jako parametr wywołania? ale to tylko szklana kula.. ostatnio coś ciemna. m ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Re: Czy php.cgi korzysta z php-cgi.ini?
Jacek Osiecki pisze: > Witam, > > Czy php-cgi.ini jest w ogóle olewane przez php.cgi? > Wpisanie czegokolwiek do tego pliku - np. zmiana max_execution_time - nie > daje absolutnie nic... Jak sprawdzam atime /etc/php/php*.ini, to jedyny > który ma zmieniany atime to /etc/php/php.ini, zaś pozostałe - w > szczególności php-cgi.ini... > > Dlaczego to nie działa? która wersja PHP, bo u mie w php-cli-5.3.1-1.10.amd64 działa? odplal "strace php.cgi" i zobacz jakich plikow konfiguracyjnych szuka. -- Rdest Arkadiusz ___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
Czy php.cgi korzysta z php-cgi.ini?
Witam, Czy php-cgi.ini jest w ogóle olewane przez php.cgi? Wpisanie czegokolwiek do tego pliku - np. zmiana max_execution_time - nie daje absolutnie nic... Jak sprawdzam atime /etc/php/php*.ini, to jedyny który ma zmieniany atime to /etc/php/php.ini, zaś pozostałe - w szczególności php-cgi.ini... Dlaczego to nie działa? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-users-pl mailing list pld-users-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
