htpasswd, php i problemy z error 500

[Miłosz 2311]

Od paru dni na jednej maszynie zauważyłem dziwny problem ze stronami, które jeszcze nie są produkcyjnie wystawione i chronione są przez podstawową autoryzację z użyciem htpasswd. Problem objawia się tak, iż raz można poprawnie się zalogować i strona działa, innym razem zaraz po tym dostajemy niemiłą 500. Jak już się wykrzaczy, to leżą wszystkie strony chronione htpasswd. Strony odpalone produkcyjnie działają w tym samym czasie bez problemów. Ktoś sie spotkał z podobnym problemem?

 

mod_fcgid w wersji 2.3.7, wersja 6 robiła to samo.

php 5.3.6

Apache 2.2.17, mpm worker

 

Z logów:

 

[Fri Aug 12 11:30:21 2011] [warn] [client 83.19.158.250] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server

[Fri Aug 12 11:30:21 2011] [error] [client 83.19.158.250] Premature end of script headers: index.php

[Fri Aug 12 11:30:25 2011] [error] mod_fcgid: process /var/www/cgi-bin/php-cgi(27990) exit(communication error), get unexpected signal 11

[megi 358]

[Fri Aug 12 11:30:25 2011] [error] mod_fcgid: process /var/www/cgi-bin/php-cgi(27990) exit(communication error), get unexpected signal 11

 

Sygnał 11 to segfault - segfaultuje Ci PHP. Takie rzeczy objawiają się w konkretnym środowisku przy wykonaniu konkretnych operacji, więc raczej nikt tutaj nie będzie Ci w stanie pomóc. Może w dmesgu będzie coś więcej? Szukaj na bugs.php.net, ale łatwiej byłoby jakbyś wiedział jak to powtórzyć - wiedziałbyś czego szukać, mógłbyś zgłosić buga.

[guziec 109]

[Fri Aug 12 11:30:25 2011] [error] mod_fcgid: process /var/www/cgi-bin/php-cgi(27990) exit(communication error), get unexpected signal 11

 

Prawdopodobnie problem sprzętowy, stawiam na zwaloną pamięć albo przegrzewający się procesor (sprawdź czy wentylator chodzi i czy radiator nie jest zawalony kurzem)

[Miłosz 2311]

Sprawdzę php, może zrobię downgrade. Aktualnie jest 5.3.6, a na starej maszynie chyba 5.3.3 (albo i jeszcze niżej).

Płyta w serwerze była wymieniana we wtorek. Z poprzednią był taki problem, że serwer dostawał w losowych odstępach czasu totalne zwiechy - pomagał tylko hard reset. Jak będę przy swoim kompie to podam więcej szczegółów.

 

Edit:

 

z dmesga:

[401172.230728] php-cgi[30495]: segfault at b7 ip 000000000077aef8 sp 00007fff09bbd260 error 4 in php-cgi[400000+63f000]
[401375.021056] php-cgi[30517]: segfault at b7 ip 000000000077aef8 sp 00007fffba645fd0 error 4 in php-cgi[400000+63f000]

 

A na starej maszynie jest nawet 5.2.14 z dotdeb.

 

#edit2:

 

Na php 5.2.17 działa stabilnie.

[guziec 109]

 

A na starej maszynie jest nawet 5.2.14 z dotdeb.

#edit2:

Na php 5.2.17 działa stabilnie.

 

 

php 5.3.6 jest już stabilne, gdyby wylatywało na pewno nie byłbyś jedynym, któremu tak się dzieje. Mówię ci - nie kombinuj, tylko sprawdź sprzęt.

http://www.bitwizard.nl/sig11/

"Most likely there is nothing wrong with your installation, your compiler or kernel. It very likely has something to do with your hardware."

[Miłosz 2311]

Wiem, że jest narazie działa dobrze na 5.2.17

[megi 358]

php 5.3.6 jest już stabilne,

 

To znaczy jedynie tyle, że developerzy poprawili znane sobie błędy (i przy okazji zrobili nowe), przetestowali na ile mogli, a nie, że przewidzieli wszystkie możliwe problemy.

 

gdyby wylatywało na pewno nie byłbyś jedynym, któremu tak się dzieje.

 

I nie jest - tu jest przykład https://bugs.php.net/bug.php?id=54646 (5.3.6 wyszło w marcu, zgłoszenie jest z maja).

Tyle, że segfault PHP u Miłosza wcale nie musi wynikać z tego samego co u tego zgłaszającego. W PHP segfaulty nie są niczym niezwykłym, samo 5.3.6 poprawia - o ile dobrze liczę - 6 segfaultów z wcześniejszych wersji.

 

Mówię ci - nie kombinuj, tylko sprawdź sprzęt.

http://www.bitwizard.nl/sig11/

"Most likely there is nothing wrong with your installation, your compiler or kernel. It very likely has something to do with your hardware."

 

Ten link odnosi się do segfaultów przy kompilacji kernela, nie ma związku z PHP.

[guziec 109]

To znaczy jedynie tyle, że developerzy poprawili znane sobie błędy (i przy okazji zrobili nowe), przetestowali na ile mogli, a nie, że przewidzieli wszystkie możliwe problemy.

 

Truizm. BTW - nowe błędy to się robi do bety, od Release Candidate do stabilnej już nowych funkcjonalności się nie dodaje, poprawia się jedynie istniejące.

 

I nie jest - tu jest przykład https://bugs.php.net/bug.php?id=54646 (5.3.6 wyszło w marcu, zgłoszenie jest z maja).

Tyle, że segfault PHP u Miłosza wcale nie musi wynikać z tego samego co u tego zgłaszającego. W PHP segfaulty nie są niczym niezwykłym, samo 5.3.6 poprawia - o ile dobrze liczę - 6 segfaultów z wcześniejszych wersji.

 

"Jeśli masz w ręku młotek, każdy problem zaczyna wyglądać jak gwóźdź". Prawda jest taka, że 99% błędóẉ związanych z sig 11 w linuksie przy stabilnych wersjach ma związek ze sprzętem - sorry. I to jest pierwsza rzecz którą się sprawdza. To że komuś tam jednemu, też się php zwala - i to w innych okolicznościach, czy że wcześniej też było kilka takich błędów, nie zmienia faktu że należy do tego jednego procenta.

 

Ten link odnosi się do segfaultów przy kompilacji kernela, nie ma związku z PHP.

 

No ja właśnie tłumaczę, że ten błąd wcale nie musi mieć związku z PHP. Tym bardziej, gdy mamy informację, że w serwerze wymieniono płytę główną.

[blackfire 185]

Truizm. BTW - nowe błędy to się robi do bety, od Release Candidate do stabilnej już nowych funkcjonalności się nie dodaje, poprawia się jedynie istniejące.

 

 

Znaczy nie śledzisz rozwoju PHP bliżej niż "o, wyszła nowa wersja" (ja całe szczęście też już nie muszę ale swojego czasu przeglądaliśmy commit po commicie z ich svna żeby zobaczyć co znowu skopali). Goście są całkowicie nieprzewidywalni. 5.3.x jest jeszcze młode, a OP aktualizował z 5.2.x, więc zmian zahaczył dużo.

 

"Jeśli masz w ręku młotek, każdy problem zaczyna wyglądać jak gwóźdź". Prawda jest taka, że 99% błędóẉ związanych z sig 11 w linuksie przy stabilnych wersjach ma związek ze sprzętem - sorry. I to jest pierwsza rzecz którą się sprawdza. To że komuś tam jednemu, też się php zwala - i to w innych okolicznościach, czy że wcześniej też było kilka takich błędów, nie zmienia faktu że należy do tego jednego procenta.

 

 

Pieprzysz aż żal czytać. Z moim zespołem z poprzedniej firmy (ohai guys, you rule!) poprawiliśmy setki segfaultów w najróżniejszym sofcie (w większości PHP, do tej pory miewam koszmary z wnętrznościami Zend VM). W tym czasie segfaultów, które udało się wyśledzić jako spowodowanych sprzętem (typu pojawiły się/zniknęły po podmianie sprzętu) było dokładnie zero. SIGSEGV wywołany sprzętem to jakaś totalna abstrakcja typu nieskorygowany błąd pamięci w bardzo specyficznym miejscu albo przegrzewające się od overclockingu procesory (abstrakcja bo mówimy tu o serwerach a nie "serwerach"). Jak już ma się pojawić jakiś widoczny z userspace problem to raczej poleci SIGBUS bo zniknął VMA podparty uszkodzonym dyskiem/filesystemem or sth, a nie segfault zawsze_tego_samego procesu z zawsze_tym_samym %rip.

 

Problemy sprzętowe są charakterystyczne, w stylu losowy zwis całego systemu (co Miłosz zaobserwował na poprzedniej płycie, która rzeczywiście mogła mieć problem) albo oopsy w driverach zdziwionych złym działaniem urządzeń. Jeżeli nie ma błędów IPMI, MCE itp., można kontrolnie memtest puścić ale jak też będzie OK to od sprzętu na 99% można się odstosunkować. Ewentualnie sumy kontrolne binariów z paczkami porównać.

 

W PHP są setki błędów związanych z liczeniem referencji, interakcją destruktorów z mechanizmami typu zarejestruj_se_handler_wyjatkow() itd. PHP bardzo lubi segfaultować po zakończeniu obsługi requestu (tak że klient nie widzi błędów tylko zostaje syf w logach). Z zachowaniem zgodności z obecnymi wersjami jest to nie do naprawienia (IIRC). Oprócz tego co jakiś czas wychodzą tradycyjne fsckupy typu NULL deref i podobne (taki sam %rip w obu wpisach w dmesgu i segfault w czasie obsługi requestu a nie po sugeruje właśnie coś takiego). Dołóż suhosina (o ironio zabugowanego jak cholera, też go poprawialiśmy), trochę syfu typu ioncube i SEGV latają na lewo i prawo.

 

Trzymając się Twojej analogii, wbijasz gwóźdź nektarynką bo młotki to 1% narzędzi w warsztacie stolarskim.

 

No ja właśnie tłumaczę, że ten błąd wcale nie musi mieć związku z PHP. Tym bardziej, gdy mamy informację, że w serwerze wymieniono płytę główną.

 

...i zaktualizowano PHP, po czym pojawiły się segfaulty w PHP i żadnym innym sofcie. To na pewno płyta główna. Miłosz: zmień płytę główną na zgodną z PHP 5.3 (ew. za 200/h Ci ten segfault znajdę i naprawię)

[megi 358]

Truizm. BTW - nowe błędy to się robi do bety, od Release Candidate do stabilnej już nowych funkcjonalności się nie dodaje, poprawia się jedynie istniejące.

 

Poprawia się błędy, które się zrobiło i o których się wie, więc w żaden sposób nie przeszkadza to robić nowych błędów pomiędzy dwoma stabilnymi wydaniami. Przy zmianie o trzecią wersję nie dodaje się nowych funkcjonalności, co nie przeszkadzało gościom od PHP dodać nowego SAPI (i w kolejnych stabilnych wydaniach poprawiać nowych błędów z tym związanych).

 

 

"Jeśli masz w ręku młotek, każdy problem zaczyna wyglądać jak gwóźdź". Prawda jest taka, że 99% błędóẉ związanych z sig 11 w linuksie przy stabilnych wersjach ma związek ze sprzętem - sorry.

 

Prawda jest taka, że sobie wymyśliłeś tę liczbę. Jeżeli nie, podaj linka do statystyk.

Cały czas mówimy o PHP a nie wszystkich innych programach. Połowa z tych segfaultów poprawionych w 5.3.6 dotyczyła 5.3.4, które też przecież wyszło jako stabilna wersja (http://www.php.net/C...Log-5.php#5.3.6). Nie odrzucaj ich, bo nie pasują do teorii. PHP po prostu nie jest przykładem dobrego softu i tyle.

 

I to jest pierwsza rzecz którą się sprawdza. To że komuś tam jednemu, też się php zwala - i to w innych okolicznościach, czy że wcześniej też było kilka takich błędów, nie zmienia faktu że należy do tego jednego procenta.

 

Kilka to było w jednym wydaniu, przy zmianie _trzeciego_ numeru wersji. W całej historii PHP tych segfaultów były setki (od 5.0.0 prawie dwieście - można policzyć w Changelogu).

 

 

No ja właśnie tłumaczę, że ten błąd wcale nie musi mieć związku z PHP. Tym bardziej, gdy mamy informację, że w serwerze wymieniono płytę główną.

 

A ja właśnie tłumacze, że takie bugi w PHP są częste i szukanie błędu tamże nie jest kombinowaniem. Jak segfaultuje gcc można podejrzewać problem sprzętowy, jak segfaultuje PHP zdecydowanie bardziej prawdopodobny jest bug w PHP.

[blackfire 185]

Odgrzeję trochę kotleta ale tego nie można przegapić w kontekście dyskusji o stabilności małych wydań PHP (x.y.z+1)

https://bugs.php.net/bug.php?id=55439

 

Nawet nie będę się wyzłośliwiał bo mi wszystko opadło jak to zobaczyłem. Po prostu przeczytajcie.