FastCGI = e500

[Gość normanos]

Nowy serwer = nowe kłopoty :/ Nienawidzę problemów na które nie mogę znaleźć rozwiązania w google

 

Konfiguracja: Apache2 + FastCGI + SuEXEC + PHP 5.2 + Ispcp

 

Bez przerwy błędy:

 

[Wed Oct 08 11:49:50 2008] [error] [client 83.28.0.144] (4)Interrupted system call: FastCGI: comm with server "/var/www/fcgi/serwer.pl/php5-fcgi-starter" aborted: select() failed, referer: http://costam

[Wed Oct 08 11:49:50 2008] [error] [client 83.28.0.144] FastCGI: incomplete headers (0 bytes) received from server "/var/www/fcgi/serwer.pl/php5-fcgi-starter", referer: http://costam

 

ustawienia startera:

export PHPRC

PHP_FCGI_CHILDREN=2

export PHP_FCGI_CHILDREN

PHP_FCGI_MAX_REQUESTS=500

export PHP_FCGI_MAX_REQUESTS

 

exec /usr/bin/php5-cgi

 

Tutaj bawiłem się i zwiększałem wartości ale niczego to nie zmieniło. Serwer jest prawie nie obciążony więc nie ma to związku z ruchem.

 

Niestety w google brak konkretów. Help me WHT, wykażcie się

[beliq 442]

uzywasz xcache ? ( tj. jest on wlaczony w php.ini )

[Gość normanos]

tak, rozwiń

 

PHP 5.2.0-8+etch13 (cgi-fcgi) (built: Sep 30 2008 18:34:20)

Copyright ? 1997-2006 The PHP Group

Zend Engine v2.2.0, Copyright ? 1998-2006 Zend Technologies

with XCache v1.2.2, Copyright ? 2005-2007, by mOo

 

edit: wyłączyłem xcache dla testu i niestety żadnej róznicy...

[Gość normanos]

żadnego pomysłu? przecież ja się tutaj zaraz potne!

[megi 358]

http://osdir.com/ml/web.fastcgi.devel/2008-08/msg00002.html

 

Możliwe, że masz ten sam problem. Nie nakładaj jednak tego patcha bo jest - cytuje - "dość wieśniacki". Spróbuj z aktualnym snapshotem - tam jest to poprawione.

http://www.fastcgi.com/dist/

[Gość normanos]

dzięki, niestety za cholerę nie chce mi się to skompilować (bez przerwy brakuje czegoś z apache), poza tym już się boję popierniczyć z paczkami debiana, już to kiedyś przerabiałem i był płacz i zgrzytanie zębami A gwarancji, że to jest z tym związane = zero :/

[MasterNETpl 100]

Dlatego zawsze tego typu rzeczy instaluje ze źródełek

[megi 358]

A gwarancji, że to jest z tym związane = zero :/

 

I tak, i nie

Komunikaty, które masz w logach i błędy 500 prawie na pewno wynikają z tego buga, który zgłosił gość. Ogólnie chodzi o to, że jak wywołanie systemowe select() zostanie przerwane jakimś sygnałem i zwróci EINTR lub EAGAIN, to mod_fastcgi *zamiast* spróbować ponownie traktuje to jako poważny błąd:

 

"Interrupted system call: (...) select() failed"

 

I to jest poprawione w tym snapshocie. Jednak dlaczego u Ciebie tyle wywołań jest przerywanych, jakim sygnałem i czy to jest wynikiem jakiegoś innego błędu to nie da się powiedzieć bez dokładnego śledztwa

[Gość normanos]

jakby wszystko miało się kompliować to takie distra jak debian nie miały by prawa bytu. Proszę mi tu nie filozofować i offtopicować ;D jakbym chciał kompilować wszystko co się rusza to wybrał bym gentoo

 

megi: spox, tylko nawet przy moich chęciach kompilacja tego wychodzi poza moją wiedzę ( /usr/share/apache2/build/rules.mk:19: *** brakuj�cy separator. Stop. ). Poza tym ciężko cokolwiek o tym wygoglać, tak jakby nikt tego nie miał

[megi 358]

wywołanie systemowe select() zostanie przerwane jakimś sygnałem i zwróci EINTR lub EAGAIN

 

Sama się poprawię select() nie zwraca EAGAIN

[Gość adamszendzielorz]

Normanos - uzywasz Zend Optimizera ? Sprobuj wylaczyc wszystkie moduly Zendowe w php.ini!

Jaka to platforma (serwer) ?

pozdr.

[Gość normanos]

nie używam, tylko xcache. To jest coś prawie jak to: http://www.ovh.pl/prywatne/produkty/superplan_best_of.xml na Debianie.

[p 3]

Zrób upgrade wszystkich komponentów do -CURRENT i sprawdź czy problem nadal występuje. W końcu nie ma sensu naprawiać błędu, który już dawno został naprawiony (Generalnie miałem to napisać już dawno temu, ale jak zobaczyłem post bellika o XCache, to myślałem, że sprawa będzie rozwiązana )

 

http://osdir.com/ml/web.fastcgi.devel/2008-08/msg00002.html

 

Możliwe, że masz ten sam problem. Nie nakładaj jednak tego patcha bo jest - cytuje - "dość wieśniacki". Spróbuj z aktualnym snapshotem - tam jest to poprawione.

Szczerze mówiąc 'poprawka' w snapshocie jest według mnie wiele bardziej 'wieśniacka'. Jeżeli z jakiś względów select() będzie ciągle przerywany, to zostaniemy z brzydką petlą while (true).

 

A gwarancji, że to jest z tym związane = zero :/

Gwarancje masz taką, że albo za którymś razem select() nie zostanie przerwany i strona się wyświetli, albo w logach zobaczysz inny błąd

[Gość normanos]

Zrób upgrade wszystkich komponentów do -CURRENT

od dawna jest etch z wszystkim z upgrade. chyba, że masz coś innego na myśli.

[p 3]

od dawna jest etch z wszystkim z upgrade. chyba, że masz coś innego na myśli.

Przez -CURRENT rozumiem wersję rozwojową z repozytorium danego projektu, ewentualnie najnowszy snapshot. Nie mylić z najnowszą stabilną wersją, ani tym bardziej z najnowszą wersją znajdującą się w paczkach jakiejś dystrybucji

[Gość normanos]

mam mod_fastcgi w najnowszej wersji 2.4.6 (a miałem 2.4.2) - nic się nie zmieniło w tym temacie. Co do snapshota to jak wyżej, za chiny nie mogę go skompilować.

 

coś poczytałem o mod_fcgid niestety nie umiem sobie poradzić z jakimś bezbolesnym przejściem na to (czyli bez edycji konfiguracji setek plików domen ).

 

edit. hmm, nie chce krakać ale czyzby czyżyk? dam znac jutro...

[TheBlood 0]

normanos, i jak - poradziłeś sobie z problemem? Jeśli tak, to podasz rozwiązanie?

Mam dokładnie ten sam problem :|

[baciarek 0]

Cześć

 

Mam identyczny problem na nazwie.pl kilka miesięcy temu zablokowali mi katalog ze skryptem i wczoraj to samo strona ładuje się bardzo długo a logach błędy z fastCGI

 

Najgorsze jest to, że goście z netart uważają że to moja wina a w skrypcie oprócz zmiany reklam ewentualnie linków nic nie grzebie bo nie potrafie

[Gość normanos]

@TheBlood: tak jak radziła @Megi, kompilacja mod_cgi w najnowszej wersji. Problem nie jest rozwiązany w 100% ale:

- występuje już rzadko, co najwyżej kilkanaście razy na dobre dla największego serwisu (wcześniej bez przerwy, w każdej minucie)

- zamieniły się komunikaty błędów z tych bezsensownych na (chyba) konkretniejsze - i to muszę jeszcze przegoglać w wolnym czasie

[TheBlood 0]

Hm, wyłączyłem zlib.output_compression w php.ini dla jednego z virtualhostów, który jest mocno odwiedzany i problem praktycznie zniknął... Zaraz potestuję jeszcze

 

Oczywiście wyłączenie kompresji to generalnie niezbyt dobre wyjście, ale zawsze jakieś

[TheBlood 0]

Istotny update : Rzeczywiście najnowszy snapshot rozwiązuje problem - logi nie są już zasypywane syfem związanym z zamykaniem procesów fastcgi, no i zniknęły logi o błedach 500. Niepokoi mnie jedynie fakt, że przy włączonym xcache apache benchmark większość requestów testowych odczytuje jako niepoprawne (np na 500 requestów 490 jest failed). Niby strony się ładują poprawnie (póki co), ale te problemy z ab mnie zastanawiają. Też tak macie?