Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Mon, 4 Jul 2011, Jacek Osiecki wrote: On Mon, 4 Jul 2011, Arkadiusz Miskiewicz wrote: On Monday 04 of July 2011, Jacek Osiecki wrote: On Sun, 3 Jul 2011, Jakub Bogusz wrote: Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. Dziś rano znowu wywaliło się identycznie - z dokładnością do adresów. Niestety zapomniałem sprawdzić jak wygląda wtedy dostęp do dev/(u)random, ale z tego co rozumiem problem faktycznie leży w libgcrypt. Leży też w th-test. Zainstalowałem. Zobaczymy, trzeba poczekać ze 2 tygodnie - jak się nie wywali ani raz, to jasny sygnał że jest OK :) No i wygląda na to że to była przyczyna problemu. Z tego co widzę, 1.5.0-1 już jest w MAIN, więc po sprawie :) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Sun, 3 Jul 2011, Jakub Bogusz wrote: On Fri, Jul 01, 2011 at 05:20:07PM +0200, Jakub Bogusz wrote: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 Loaded symbols for /usr/lib64/php/zlib.so 0x666af9bda430 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) continue Continuing. Catchpoint 1 (call to syscall 'select'), 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 add_randomness, origin=RANDOM_ORIGIN_SLOWPOLL,length=120, level=value optimized out) at rndlinux.c:133 No to błąd do zgłoszenia w libgcrypt: przy tworzeniu zbioru dla select() nie ma sprawdzenia, czy otrzymany deskryptor nie przekracza FD_SETSIZE. Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. Dziś rano znowu wywaliło się identycznie - z dokładnością do adresów. Niestety zapomniałem sprawdzić jak wygląda wtedy dostęp do dev/(u)random, ale z tego co rozumiem problem faktycznie leży w libgcrypt. Na razie trochę boję się bawić w kompilowanie od zera z CVSu - gdzieś tam mam przepis jak się budowało pakiety, spróbuję jak tylko będzie chwila... Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Monday 04 of July 2011, Jacek Osiecki wrote: On Sun, 3 Jul 2011, Jakub Bogusz wrote: Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. Dziś rano znowu wywaliło się identycznie - z dokładnością do adresów. Niestety zapomniałem sprawdzić jak wygląda wtedy dostęp do dev/(u)random, ale z tego co rozumiem problem faktycznie leży w libgcrypt. Na razie trochę boję się bawić w kompilowanie od zera z CVSu - gdzieś tam mam przepis jak się budowało pakiety, spróbuję jak tylko będzie chwila... Leży też w th-test. Pozdrawiam, -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Mon, 4 Jul 2011, Arkadiusz Miskiewicz wrote: On Monday 04 of July 2011, Jacek Osiecki wrote: On Sun, 3 Jul 2011, Jakub Bogusz wrote: Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. Dziś rano znowu wywaliło się identycznie - z dokładnością do adresów. Niestety zapomniałem sprawdzić jak wygląda wtedy dostęp do dev/(u)random, ale z tego co rozumiem problem faktycznie leży w libgcrypt. Na razie trochę boję się bawić w kompilowanie od zera z CVSu - gdzieś tam mam przepis jak się budowało pakiety, spróbuję jak tylko będzie chwila... Leży też w th-test. Zainstalowałem. Zobaczymy, trzeba poczekać ze 2 tygodnie - jak się nie wywali ani raz, to jasny sygnał że jest OK :) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Fri, Jul 01, 2011 at 05:20:07PM +0200, Jakub Bogusz wrote: On Fri, Jul 01, 2011 at 08:33:11AM +0200, Jacek Osiecki wrote: On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 12:10:27 Jacek Osiecki wrote: On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 ^ doinstaluj jeszcze pakiety -debuginfo, t obedzie cos wiecej widac. No tego właśnie się obawiałem ;) Zobaczymy - jeśli po tych upgrade'ach które zrobiłem problem nie wystąpi, to sprawa zamknięta. Jeśli wystąpi, to zainstaluję debuginfo i się zobaczy co z tego wyniknie. No i znowu było bum, mimo wszelkich upgrade'ów... Tym razem były pakiety debuginfo. chyba jednak nie php jest winne... a może się mylę? Loaded symbols for /usr/lib64/php/zlib.so 0x666af9bda430 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) continue Continuing. Catchpoint 1 (call to syscall 'select'), 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 add_randomness, origin=RANDOM_ORIGIN_SLOWPOLL,length=120, level=value optimized out) at rndlinux.c:133 No to błąd do zgłoszenia w libgcrypt: przy tworzeniu zbioru dla select() nie ma sprawdzenia, czy otrzymany deskryptor nie przekracza FD_SETSIZE. Czyli mamy przepełnienie zmiennej na stosie. W przypadku kiedy deskryptor nieznacznie przekracza FD_SETSIZE (=1024 normalnie), to nadpisuje zmienną zawierającą timeout (ewentualnie zmiana tej zmiennej zmienia wartość tego, co potem select() ze zbyt dużym pierwszym parametrem uważa za fdset). Tak w ogóle to zamiast select()a tam powinien być poll() i by nie było problemu. Deskryptor jest jeden, więc nie ma sensu używanie epolla. Swoją drogą to ciekawe, ile jeszcze bibliotek korzysta z select()a, przez co ma podobne problemy w przypadku przekroczenia 1024 deskryptorów w ramach procesu... apache+php tworzy środowisko podatne na takie błędy. Doraźnie - zapewne uruchamianie php via fcgi albo wyłączenie curla by problem wyeliminowało. Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 12:10:27 Jacek Osiecki wrote: On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 ^ doinstaluj jeszcze pakiety -debuginfo, t obedzie cos wiecej widac. No tego właśnie się obawiałem ;) Zobaczymy - jeśli po tych upgrade'ach które zrobiłem problem nie wystąpi, to sprawa zamknięta. Jeśli wystąpi, to zainstaluję debuginfo i się zobaczy co z tego wyniknie. No i znowu było bum, mimo wszelkich upgrade'ów... Tym razem były pakiety debuginfo. chyba jednak nie php jest winne... a może się mylę? Loaded symbols for /usr/lib64/php/zlib.so 0x666af9bda430 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) continue Continuing. Catchpoint 1 (call to syscall 'select'), 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 add_randomness, origin=RANDOM_ORIGIN_SLOWPOLL,length=120, level=value optimized out) at rndlinux.c:133 #2 0x666ae6d692e0 in read_random_source (orgin=value optimized out, length=value optimized out,level=value optimized out) at random-csprng.c:1272 #3 0x666ae6d6a18c in random_poll (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1106 #4 read_pool (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1000 #5 _gcry_rngcsprng_randomize (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:551 #6 0x666ae6d6a8fd in _gcry_rngcsprng_create_nonce (buffer=0x74989dc17c4f, length=1) at random-csprng.c:1366 #7 0x666ae72458c7 in wrap_gcry_rnd_init (ctx=value optimized out) at rnd.c:39 #8 0x666ae71ef50b in _gnutls_rnd_init () at random.c:39 #9 0x666ae71de94e in gnutls_global_init () at gnutls_global.c:219 #10 0x666ae9362267 in Curl_gtls_init () from /usr/lib64/libcurl.so.4 #11 0x666ae93543a9 in curl_global_init () from /usr/lib64/libcurl.so.4 #12 0x666ae958f18c in zm_startup_curl () from /usr/lib64/php/curl.so #13 0x666af1ec2df7 in zend_startup_module_ex () from /usr/lib64/libphp_common-5.2.13.so #14 0x666af1ecdc5a in zend_hash_apply () from /usr/lib64/libphp_common-5.2.13.so #15 0x666af1ec6280 in zend_startup_modules () from /usr/lib64/libphp_common-5.2.13.so #16 0x666af1e74fc7 in php_module_startup () from /usr/lib64/libphp_common-5.2.13.so #17 0x666af221d315 in ?? () from /etc/httpd/modules/libphp5.so #18 0x666af221e17a in ?? () from /etc/httpd/modules/libphp5.so #19 0x00439206 in ap_run_post_config () #20 0x00424ac6 in main () (gdb) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
Prawdopodobnie masz jakis problem z dostepem do /dev/random badz /dev/urandom. On pią, 2011-07-01 at 08:33 +0200, Jacek Osiecki wrote: On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 12:10:27 Jacek Osiecki wrote: On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 ^ doinstaluj jeszcze pakiety -debuginfo, t obedzie cos wiecej widac. No tego właśnie się obawiałem ;) Zobaczymy - jeśli po tych upgrade'ach które zrobiłem problem nie wystąpi, to sprawa zamknięta. Jeśli wystąpi, to zainstaluję debuginfo i się zobaczy co z tego wyniknie. No i znowu było bum, mimo wszelkich upgrade'ów... Tym razem były pakiety debuginfo. chyba jednak nie php jest winne... a może się mylę? Loaded symbols for /usr/lib64/php/zlib.so 0x666af9bda430 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) continue Continuing. Catchpoint 1 (call to syscall 'select'), 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 add_randomness, origin=RANDOM_ORIGIN_SLOWPOLL,length=120, level=value optimized out) at rndlinux.c:133 #2 0x666ae6d692e0 in read_random_source (orgin=value optimized out, length=value optimized out,level=value optimized out) at random-csprng.c:1272 #3 0x666ae6d6a18c in random_poll (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1106 #4 read_pool (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1000 #5 _gcry_rngcsprng_randomize (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:551 #6 0x666ae6d6a8fd in _gcry_rngcsprng_create_nonce (buffer=0x74989dc17c4f, length=1) at random-csprng.c:1366 #7 0x666ae72458c7 in wrap_gcry_rnd_init (ctx=value optimized out) at rnd.c:39 #8 0x666ae71ef50b in _gnutls_rnd_init () at random.c:39 #9 0x666ae71de94e in gnutls_global_init () at gnutls_global.c:219 #10 0x666ae9362267 in Curl_gtls_init () from /usr/lib64/libcurl.so.4 #11 0x666ae93543a9 in curl_global_init () from /usr/lib64/libcurl.so.4 #12 0x666ae958f18c in zm_startup_curl () from /usr/lib64/php/curl.so #13 0x666af1ec2df7 in zend_startup_module_ex () from /usr/lib64/libphp_common-5.2.13.so #14 0x666af1ecdc5a in zend_hash_apply () from /usr/lib64/libphp_common-5.2.13.so #15 0x666af1ec6280 in zend_startup_modules () from /usr/lib64/libphp_common-5.2.13.so #16 0x666af1e74fc7 in php_module_startup () from /usr/lib64/libphp_common-5.2.13.so #17 0x666af221d315 in ?? () from /etc/httpd/modules/libphp5.so #18 0x666af221e17a in ?? () from /etc/httpd/modules/libphp5.so #19 0x00439206 in ap_run_post_config () #20 0x00424ac6 in main () (gdb) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Fri, 1 Jul 2011, Jan Palus wrote: Prawdopodobnie masz jakis problem z dostepem do /dev/random badz /dev/urandom. (gdb) bt #0 0x666af9be1b23 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 #1 0x666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 add_randomness, origin=RANDOM_ORIGIN_SLOWPOLL,length=120, level=value optimized out) at rndlinux.c:133 #2 0x666ae6d692e0 in read_random_source (orgin=value optimized out, length=value optimized out,level=value optimized out) at random-csprng.c:1272 #3 0x666ae6d6a18c in random_poll (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1106 #4 read_pool (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:1000 #5 _gcry_rngcsprng_randomize (buffer=0x666ae6f9ba04, length=8, level=value optimized out) at random-csprng.c:551 #6 0x666ae6d6a8fd in _gcry_rngcsprng_create_nonce (buffer=0x74989dc17c4f, length=1) at random-csprng.c:1366 Hmm, i tak by niedeterministycznie się objawiał? Pliki /dev/*random raczej w porządku: crw-rw-rw- 1 root root 1, 8 Jun 25 09:00 /dev/random crw-rw-rw- 1 root root 1, 9 Jun 25 09:00 /dev/urandom Mam kernel z grsec (nie dystrybucyjny, własnoręcznie kompilowany) i nie widzę też by grsec cokolwiek w logach pisał (poza wiecznym segmentation fault javy, który chyba jest stałym widokiem przy połączeniu grsec+java) -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
Jacek Osiecki wrote: Hmm, i tak by niedeterministycznie się objawiał? Pliki /dev/*random raczej w porządku: crw-rw-rw- 1 root root 1, 8 Jun 25 09:00 /dev/random crw-rw-rw- 1 root root 1, 9 Jun 25 09:00 /dev/urandom Mam kernel z grsec (nie dystrybucyjny, własnoręcznie kompilowany) i nie widzę też by grsec cokolwiek w logach pisał (poza wiecznym segmentation fault javy, który chyba jest stałym widokiem przy połączeniu grsec+java) A zobacz, czy jak to się dzieje (bez restartu apache'a), to możesz odczytać coś z /dev/random i /dev/urandom (np. hexdump -C /dev/random). /dev/random blokuje i tam może być mało wyniku ale /dev/urandom (a najprawdopopdobniej ten jest wykorzystywany przez libgcrypt) powinien być czytalny bez opóźnień. Zerknij też, co w takim przypadku jest w /proc/sys/kernel/random/poolsize i /proc/sys/kernel/random/entropy_avail. Kiedyś miałem przypadek, że /dev/random się całkowicie ,,opróżnił'', czyli przez dłuższy czas za każdym razem odczyt z niego mówił, że jest koniec pliku. Pomógł dopiero reboot. Może u Ciebie coś podobnego się dzieje na /dev/urandom. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Fri, 1 Jul 2011, Adam Osuchowski wrote: Jacek Osiecki wrote: Pliki /dev/*random raczej w porządku: crw-rw-rw- 1 root root 1, 8 Jun 25 09:00 /dev/random crw-rw-rw- 1 root root 1, 9 Jun 25 09:00 /dev/urandom A zobacz, czy jak to się dzieje (bez restartu apache'a), to możesz odczytać coś z /dev/random i /dev/urandom (np. hexdump -C /dev/random). /dev/random blokuje i tam może być mało wyniku ale /dev/urandom (a najprawdopopdobniej ten jest wykorzystywany przez libgcrypt) powinien być czytalny bez opóźnień. Zerknij też, co w takim przypadku jest w /proc/sys/kernel/random/poolsize i /proc/sys/kernel/random/entropy_avail. OK, sprawdzę bo widzę że niestety to się będzie powtarzać (kurde, chyba zmienię cron.daily na 7 rano to wtedy usłyszę SMSa od nagiosa :) Kiedyś miałem przypadek, że /dev/random się całkowicie ,,opróżnił'', czyli przez dłuższy czas za każdym razem odczyt z niego mówił, że jest koniec pliku. Pomógł dopiero reboot. Może u Ciebie coś podobnego się dzieje na /dev/urandom. Akurat ostatnio był reboot (po bodajże 200 dniach uptime'u), od tego czasu już ze dwa razy były te cyrki... Czyli rozumiem że zdecydowanie php oczyszczone z zarzutów? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
Jacek Osiecki wrote: Czyli rozumiem że zdecydowanie php oczyszczone z zarzutów? Raczej tak. gdb wskazuje bardziej, że bezpośrednio winny jest libgcrypt, co nie znaczy, że zasadnicza przyczyna problemu nie leży gdzieś indziej. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi? (kolejny pad, z debuginfo)
On Fri, Jul 01, 2011 at 10:30:41 +0200, Jacek Osiecki wrote: OK, sprawdzę bo widzę że niestety to się będzie powtarzać (kurde, chyba zmienię cron.daily na 7 rano to wtedy usłyszę SMSa od nagiosa :) monit-rc-apache? Mój apache zdycha parę razy w tygodniu, już dawno przestało mnie to obchodzić. Raz na miesiąc mam też pad saslauthd, ale właśnie do załatwiania powtarzalnych problemów są odpowiednie narzędzia. Czyli rozumiem że zdecydowanie php oczyszczone z zarzutów? Ha ha:) Żebyś się nie zdziwił. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Mon, 27 Jun 2011, Adam Osuchowski wrote: Jacek Osiecki wrote: OK, to przy następnym padzie zrobię jak podajesz :) Czyli jak rozumiem: catch syscall, potem continue, potem bt? Jeśli ,,catch syscall select'' nie złapie tego syscalla (gdb czasami tak ma) to daj samo ,,catch syscall''. Skoro w krytycznym momencie, jak pisałeś, i tak jest wywoływany w kółko select(), to na jedno wyjdzie. No więc wygląda na to, że ta wywałka zawsze występuje po /etc/init.d/httpd reload - nie po każdym, ciężko znaleźć jakąś regułę. Dziś zrobiłem reload - i trafione. Jako że duużo tego, to wrzuciłem na pastebin: http://pastebin.com/43RBxabQ Czy to oznacza że bug jest bardziej w php, czy jednak w glibc lub libgcrypt? Widzę że jest już glibc-2.14-11.x86_64, a u mnie jest glibc-2.13-6.x86_64. Upgrade nawet nie wywołuje lawiny zależności, więc spróbuję zacząć od tego. Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, 29 Jun 2011, Jacek Osiecki wrote: On Mon, 27 Jun 2011, Adam Osuchowski wrote: Jeśli ,,catch syscall select'' nie złapie tego syscalla (gdb czasami tak ma) to daj samo ,,catch syscall''. Skoro w krytycznym momencie, jak pisałeś, i tak jest wywoływany w kółko select(), to na jedno wyjdzie. No więc wygląda na to, że ta wywałka zawsze występuje po /etc/init.d/httpd reload - nie po każdym, ciężko znaleźć jakąś regułę. Dziś zrobiłem reload - i trafione. Dodam jeszcze, że zadziałało catch syscall select. Jako że duużo tego, to wrzuciłem na pastebin: http://pastebin.com/43RBxabQ Hmm, pastebin kota pokazuje :) Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 #5 0x74b575afc257 in ?? () from /usr/lib64/libgnutls.so.26 #6 0x74b575afa4dc in ?? () from /usr/lib64/libgnutls.so.26 #7 0x74b575aebc56 in gnutls_global_init () from /usr/lib64/libgnutls.so.26 #8 0x74b577c54027 in Curl_gtls_init () from /usr/lib64/libcurl.so.4 #9 0x74b577c45da9 in curl_global_init () from /usr/lib64/libcurl.so.4 #10 0x74b577e7f18c in zm_startup_curl () from /usr/lib64/php/curl.so #11 0x74b5803b1df7 in zend_startup_module_ex () from /usr/lib64/libphp_common-5.2.13.so #12 0x74b5803bcc5a in zend_hash_apply () from /usr/lib64/libphp_common-5.2.13.so #13 0x74b5803b5280 in zend_startup_modules () from /usr/lib64/libphp_common-5.2.13.so #14 0x74b580363fc7 in php_module_startup () from /usr/lib64/libphp_common-5.2.13.so #15 0x74b58070c315 in ?? () from /etc/httpd/modules/libphp5.so #16 0x74b58070d17a in ?? () from /etc/httpd/modules/libphp5.so #17 0x004391f6 in ap_run_post_config () #18 0x00424ab6 in main () (gdb) quit I po wstępnym dochodzeniu zrobiłem parę upgrade'ów by mieć aktualne wszystko co jest na powyższej liście aż do punktu #10 - potem jest już php, którego na razie nie mogę upgrade'ować glibc-2.13-6.x86_64 - glibc-2.14-11.x86_64 libgcrypt-1.4.4-2.x86_64 - libgcrypt-1.4.6-1.x86_64 gnutls-2.8.3-1.x86_64 - gnutls-2.12.5-1.x86_64 curl-libs-7.21.2-1.x86_64 - curl-libs-7.21.7-1.x86_64 Następnie, patrząc na to co pokazuje ldd na /usr/lib64/libphp_common-5.2.13.so zrobiłem jeszcze upgrade: libxml2-2.7.8-1.x86_64 - libxml2-2.7.8-2.x86_64 zlib-1.2.5-3.x86_64 - zlib-1.2.5-5.x86_64 nss-softokn-freebl-3.12.3-3.x86_64 - nss-softokn-freebl-3.12.9-1.x86_64 Zobaczymy jak będzie teraz, mam nadzieję że problemy ustąpią :) Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 ^ doinstaluj jeszcze pakiety -debuginfo, t obedzie cos wiecej widac. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, 29 Jun 2011, Pawel Sikora wrote: On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: Pozwolę sobie więc wrzucić końcówkę z gdb: (gdb) bt #0 0x74b5880c8243 in select () from /lib64/libc.so.6 #1 0x74b575680119 in ?? () from /lib64/libgcrypt.so.11 #2 0x74b57567d630 in ?? () from /lib64/libgcrypt.so.11 #3 0x74b57567e914 in ?? () from /lib64/libgcrypt.so.11 #4 0x74b57567d9bf in ?? () from /lib64/libgcrypt.so.11 ^ doinstaluj jeszcze pakiety -debuginfo, t obedzie cos wiecej widac. No tego właśnie się obawiałem ;) Zobaczymy - jeśli po tych upgrade'ach które zrobiłem problem nie wystąpi, to sprawa zamknięta. Jeśli wystąpi, to zainstaluję debuginfo i się zobaczy co z tego wyniknie. Jak rozumiem, debuginfo to alternatywna wersja pakietu po prostu bez zapuszczonego stripa - i nie ma negatywnego wpływu na wydajność? Jak je instalować - pobrać ftpem i instalować rpmem z --force? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, Jun 29, 2011 at 09:27:30 +0200, Jacek Osiecki wrote: No więc wygląda na to, że ta wywałka zawsze występuje po /etc/init.d/httpd reload - nie po każdym, ciężko znaleźć jakąś regułę. Dziś zrobiłem reload - i trafione. To tak tylko dla nawiązania: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-December/143831.html -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, 29 Jun 2011, Tomasz Pala wrote: On Wed, Jun 29, 2011 at 09:27:30 +0200, Jacek Osiecki wrote: No więc wygląda na to, że ta wywałka zawsze występuje po /etc/init.d/httpd reload - nie po każdym, ciężko znaleźć jakąś regułę. Dziś zrobiłem reload - i trafione. To tak tylko dla nawiązania: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-December/143831.html Chyba nie do końca to... mam mysql 5.1.47 (też nie był upgrade'owany, bo by wymusił php 5.3). No i nie każdy reload robi masakrę :) A debuginfo na wszelki wypadek doinstalowałem, poczekamy-zobaczymy. Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
Jacek Osiecki wrote: 0x70ccc8a27590 in write () from /lib64/libc.so.6 (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) bt Po catch syscall daj continue. Teraz bt pokazał Ci miejsce w którym gdb przerwał działanie procesu przy podłączeniu. Czy to faktycznie przyczyną jest PHP, skoro widzę Catchpoint 1 (syscall 'select' [23]) a #23 to libphp5.so? Nie, 23 to jest numer selecta na x86-64. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Mon, 27 Jun 2011, Adam Osuchowski wrote: Jacek Osiecki wrote: 0x70ccc8a27590 in write () from /lib64/libc.so.6 (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) bt Po catch syscall daj continue. Teraz bt pokazał Ci miejsce w którym gdb przerwał działanie procesu przy podłączeniu. OK, to przy następnym padzie zrobię jak podajesz :) Czyli jak rozumiem: catch syscall, potem continue, potem bt? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Monday 27 of June 2011, Jacek Osiecki wrote: On Mon, 27 Jun 2011, Adam Osuchowski wrote: Jacek Osiecki wrote: 0x70ccc8a27590 in write () from /lib64/libc.so.6 (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) bt Po catch syscall daj continue. Teraz bt pokazał Ci miejsce w którym gdb przerwał działanie procesu przy podłączeniu. OK, to przy następnym padzie zrobię jak podajesz :) Czyli jak rozumiem: catch syscall, potem continue, potem bt? W th-obsolete jest też przemielony php5.2 na wszelki wypadek gdyby jednak poprzedni build był zrobiony na zwalonym builderze. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
Jacek Osiecki wrote: OK, to przy następnym padzie zrobię jak podajesz :) Czyli jak rozumiem: catch syscall, potem continue, potem bt? Jeśli ,,catch syscall select'' nie złapie tego syscalla (gdb czasami tak ma) to daj samo ,,catch syscall''. Skoro w krytycznym momencie, jak pisałeś, i tak jest wywoływany w kółko select(), to na jedno wyjdzie. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Thu, 23 Jun 2011, Adam Osuchowski wrote: Jacek Osiecki wrote: No tu to już naprawdę bez szans, bo to się dzieje tylko na jednej maszynie produkcyjnej - tak na oko jakoś raz na tydzień-dwa... No to jak się to znów pojawi, to podłącz się gdb-em, włącz łapanie syscalla select() (catch syscall select) i zobacz spod jakiego adresu ten select jest wołany (backtrace). Później obejrzyj /proc/pid/maps i dopasuj, w którym z zamapowanych plików leży ten adres. Pozwoli to określić, czy bezpośrednim winnym jest core apache'a czy jakiś moduł. No więc stało się znowu. Strace pokazał dokładnie to samo. Apache bez debuginfo, więc gdb chyba nie daje wszystkich informacji, ale: 0x70ccc8a27590 in write () from /lib64/libc.so.6 (gdb) catch syscall select Catchpoint 1 (syscall 'select' [23]) (gdb) bt #0 0x70ccc8a27590 in write () from /lib64/libc.so.6 #1 0x70ccc89cb973 in _IO_file_write () from /lib64/libc.so.6 #2 0x70ccc89cb61a in ?? () from /lib64/libc.so.6 #3 0x70ccc89cc805 in _IO_do_write () from /lib64/libc.so.6 #4 0x70ccc89cb77d in _IO_file_xsputn () from /lib64/libc.so.6 #5 0x70ccc899ed45 in vfprintf () from /lib64/libc.so.6 #6 0x70ccc8a48f4f in __vfprintf_chk () from /lib64/libc.so.6 #7 0x70ccb5fa7414 in ?? () from /lib64/libgcrypt.so.11 #8 0x70ccb5fa7905 in ?? () from /lib64/libgcrypt.so.11 #9 0x70ccb5fe622e in ?? () from /lib64/libgcrypt.so.11 #10 0x70ccb5fe3630 in ?? () from /lib64/libgcrypt.so.11 #11 0x70ccb5fe4914 in ?? () from /lib64/libgcrypt.so.11 #12 0x70ccb5fe39bf in ?? () from /lib64/libgcrypt.so.11 #13 0x70ccb6462257 in ?? () from /usr/lib64/libgnutls.so.26 #14 0x70ccb64604dc in ?? () from /usr/lib64/libgnutls.so.26 #15 0x70ccb6451c56 in gnutls_global_init () from /usr/lib64/libgnutls.so.26 #16 0x70ccb85ba027 in Curl_gtls_init () from /usr/lib64/libcurl.so.4 #17 0x70ccb85abda9 in curl_global_init () from /usr/lib64/libcurl.so.4 #18 0x70ccb87e518c in zm_startup_curl () from /usr/lib64/php/curl.so #19 0x70ccc0d17df7 in zend_startup_module_ex () from /usr/lib64/libphp_common-5.2.13.so #20 0x70ccc0d22c5a in zend_hash_apply () from /usr/lib64/libphp_common-5.2.13.so #21 0x70ccc0d1b280 in zend_startup_modules () from /usr/lib64/libphp_common-5.2.13.so #22 0x70ccc0cc9fc7 in php_module_startup () from /usr/lib64/libphp_common-5.2.13.so #23 0x70ccc1072315 in ?? () from /etc/httpd/modules/libphp5.so #24 0x70ccc107317a in ?? () from /etc/httpd/modules/libphp5.so #25 0x004391f6 in ap_run_post_config () #26 0x00424ab6 in main () Czy to faktycznie przyczyną jest PHP, skoro widzę Catchpoint 1 (syscall 'select' [23]) a #23 to libphp5.so? Patrzyłem do proc/pid apache/maps ale nie wiem za bardzo czego tam szukać... Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, 22 Jun 2011, Arkadiusz Miskiewicz wrote:
On Wednesday 22 of June 2011, Jakub Bogusz wrote:
Po zrobieniu na nim strace zobaczyłem generowane xset linii na sekundę:
select(1088, [1024 1025 1087], NULL, NULL, {9223372036854775811, 0}) = -1
EINVAL (Invalid argument)
timeout jest błędny i to jest przyczyna EINVAL, ale kto tak skrzywdził
tę wersję Apache'a (która to w ogóle)?
rpm -q apache by się przydał - przez parę dni parę tygodni temu na builderze
x86_64 była paczka glibc-headers z i686 przez co budowały się zwalone
paczki... Potem poszły rebuildy i obecne wersje są fixnięte.
Tak jak pisałem, apache aktualny - jedynie mod_php stary, bo nie chcę
ryzykować przejścia z php 5.2 na 5.3.
Czyli konkretniej - apache i jego moduły w wersji 2.2.19-1 x86_64.
Pozdrawiam,
--
Jacek Osiecki jos...@ceti.pl GG:3828944
I don't want something I need. I want something I want.___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Thursday 23 of June 2011, Jacek Osiecki wrote: Tak jak pisałem, apache aktualny - jedynie mod_php stary, bo nie chcę ryzykować przejścia z php 5.2 na 5.3. Czyli konkretniej - apache i jego moduły w wersji 2.2.19-1 x86_64. rpm -q php-common ew. data builda? -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Thu, 23 Jun 2011, Arkadiusz Miskiewicz wrote: On Thursday 23 of June 2011, Jacek Osiecki wrote: Tak jak pisałem, apache aktualny - jedynie mod_php stary, bo nie chcę ryzykować przejścia z php 5.2 na 5.3. Czyli konkretniej - apache i jego moduły w wersji 2.2.19-1 x86_64. rpm -q php-common ew. data builda? Name: php-common Relocations: (not relocatable) Version : 5.2.13Vendor: (none) Release : 12Build Date: Sun 16 May 2010 12:53:23 PM CEST Install Date: Tue 20 Jul 2010 01:32:38 PM Build Host: ymir-builder Group : Libraries Source RPM: php-5.2.13-12.src.rpm Size: 3475804 License: PHP Signature : DSA/SHA1, Wed 19 May 2010 08:23:07 AM CEST, Key ID af3f93bce4f1bc2d Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, 22 Jun 2011, Adam Osuchowski wrote:
Jacek Osiecki wrote:
Po zrobieniu na nim strace zobaczyłem generowane xset linii na sekundę:
select(1088, [1024 1025 1087], NULL, NULL, {9223372036854775811, 0}) = -1
EINVAL (Invalid argument)
Ten timeout jest dziwny. 9223372036854775811 na 64 bitach jest wartością
ujemną. Sugerowałbym błąd w kodzie, który wywołuje selecta z ujemnym
timeoutem. Ja bym przekompilował to z informacjami dla debuggera, a jak
problem wystąpi to podłączył się gdb i zobaczył w którym miejscu jest ten
felerny select(). Później trzebaby obejrzeć to miejsce w kodzie źródłowym.
No tu to już naprawdę bez szans, bo to się dzieje tylko na jednej maszynie
produkcyjnej - tak na oko jakoś raz na tydzień-dwa...
Z apache'owych rzeczy mam tylko apache-mod_php nieaktualny - bo 5.2.13
jako że boję się wrzucić 5.3.6 ze względu na niekompatybilność...
Swoją drogą ta wartość to jest w hexie 0x8003. Obstawiam, że
miało być oryginalnie 3 ale się komuś ustawił najstarszy bit.
Zrzuciłem lsof do pliku... czego w nim szukać?
Tutaj akurat lsof raczej nic nie da.
Tak przypuszczałem widząc ten numerek ;)
Nie zmienia to faktu, że nie jestem jedynym któremu to się zdarzyło -
przynajmniej jeśli chodzi o PLD...
Pozdrawiam,
--
Jacek Osiecki jos...@ceti.pl GG:3828944
I don't want something I need. I want something I want.___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wed, Jun 22, 2011 at 08:17:37AM +0200, Jacek Osiecki wrote:
On Thu, 16 Jun 2011, Jacek Osiecki wrote:
On Mon, 13 Jun 2011, Arkadiusz Miskiewicz wrote:
Już drugi raz widzę coś takiego:
Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i nagle
zaczął siać do error_log milionami komunikatów:
select() error: Invalid argument
Zrób strace, poznasz deskryptor na którym ten select() się odbywa, zobacz
lsof czy czymś podobnym czego dotyczy ów deskryptor - może tą drogą
dojdziesz
do sedna (to może być którykolwiek moduł apacza).
No dobra, znowu się stało. Tak samo jak ostatnio, czyli w logu apache'a
jest info o restarcie a potem już tylko cała seria:
select() error: Invalid argument
Nie wiem czy apache działał, bo jak się obudziłem to już nie miał szans
działać - powyższy komunikat zajął pozostałe 36GB /var i wszystko leżało.
Wszystkie procesy apache'a poza jednym były defunct
Po zrobieniu na nim strace zobaczyłem generowane xset linii na sekundę:
select(1088, [1024 1025 1087], NULL, NULL, {9223372036854775811, 0}) = -1
EINVAL (Invalid argument)
timeout jest błędny i to jest przyczyna EINVAL, ale kto tak skrzywdził
tę wersję Apache'a (która to w ogóle)?
Dlaczego używany jest select(), a nie epoll (lub przynajmniej poll)
i dlaczego numery deskryptorów przekraczają standardowe FD_SETSIZE?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Wednesday 22 of June 2011, Jakub Bogusz wrote:
On Wed, Jun 22, 2011 at 08:17:37AM +0200, Jacek Osiecki wrote:
On Thu, 16 Jun 2011, Jacek Osiecki wrote:
On Mon, 13 Jun 2011, Arkadiusz Miskiewicz wrote:
Już drugi raz widzę coś takiego:
Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i
nagle zaczął siać do error_log milionami komunikatów:
select() error: Invalid argument
Zrób strace, poznasz deskryptor na którym ten select() się odbywa,
zobacz lsof czy czymś podobnym czego dotyczy ów deskryptor - może tą
drogą dojdziesz do sedna (to może być którykolwiek moduł apacza).
No dobra, znowu się stało. Tak samo jak ostatnio, czyli w logu apache'a
jest info o restarcie a potem już tylko cała seria:
select() error: Invalid argument
Nie wiem czy apache działał, bo jak się obudziłem to już nie miał szans
działać - powyższy komunikat zajął pozostałe 36GB /var i wszystko leżało.
Wszystkie procesy apache'a poza jednym były defunct
Po zrobieniu na nim strace zobaczyłem generowane xset linii na sekundę:
select(1088, [1024 1025 1087], NULL, NULL, {9223372036854775811, 0}) = -1
EINVAL (Invalid argument)
timeout jest błędny i to jest przyczyna EINVAL, ale kto tak skrzywdził
tę wersję Apache'a (która to w ogóle)?
rpm -q apache by się przydał - przez parę dni parę tygodni temu na builderze
x86_64 była paczka glibc-headers z i686 przez co budowały się zwalone
paczki... Potem poszły rebuildy i obecne wersje są fixnięte.
--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Sun, 5 Jun 2011, Paweł wrote: Dnia niedziela 05 czerwiec 2011, Jacek Osiecki napisał: Już drugi raz widzę coś takiego: Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i nagle zaczął siać do error_log milionami komunikatów: select() error: Invalid argument ... i tak aż do zapełnienia dysku. Apache i jego moduły (oprócz mod_php) jak najbardziej aktualny... Jakieś pomysły gdzie szukać winnych? Miałem bardzo podobne zdarzenie wczoraj wieczorem, ale raczej niezwiązane z rotacją logów. Na szczęście bylem on line i szybkie skasowanie error_log uratowało serwer przed padem. Oprócz tego apache powoli po kawałku zjada mi RAM - około 10 MB na godzinę. Nigdzie (w top ani przy spisie czynnych procesów) nie widać winnego, wszystkie forki httpd raportują po 0.5% mem, ale restart httpd zwalnia skokowo 2.5 GB z 4 GB fizycznej pamięci. Ti aktualne, apache też. Oprócz tego na Dzisiaj znowu to samo. Faktycznie nie ma nic wspólnego z rotacją logów, po prostu się zdarza i tyle. 50GB /var/log/httpd/error_log zapchane komunikatami: select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument Nikt nie ma pomysłu co to może być? Pozdrawiam, -- Jacek Osiecki jos...@ceti.pl GG:3828944 I don't want something I need. I want something I want.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
W dniu 13 czerwca 2011 08:02 użytkownik Jacek Osiecki jos...@hybrid.pl napisał: On Sun, 5 Jun 2011, Paweł wrote: Dnia niedziela 05 czerwiec 2011, Jacek Osiecki napisał: Już drugi raz widzę coś takiego: Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i nagle zaczął siać do error_log milionami komunikatów: select() error: Invalid argument ... i tak aż do zapełnienia dysku. Apache i jego moduły (oprócz mod_php) jak najbardziej aktualny... Jakieś pomysły gdzie szukać winnych? Miałem bardzo podobne zdarzenie wczoraj wieczorem, ale raczej niezwiązane z rotacją logów. Na szczęście bylem on line i szybkie skasowanie error_log uratowało serwer przed padem. Oprócz tego apache powoli po kawałku zjada mi RAM - około 10 MB na godzinę. Nigdzie (w top ani przy spisie czynnych procesów) nie widać winnego, wszystkie forki httpd raportują po 0.5% mem, ale restart httpd zwalnia skokowo 2.5 GB z 4 GB fizycznej pamięci. Ti aktualne, apache też. Oprócz tego na Dzisiaj znowu to samo. Faktycznie nie ma nic wspólnego z rotacją logów, po prostu się zdarza i tyle. 50GB /var/log/httpd/error_log zapchane komunikatami: select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument Nikt nie ma pomysłu co to może być? Ti stable + Ti-test a z niego Apache 2.2.19. Takich objawów w ogóle nie miałem nigdy, a przegrzebałem nawet wszystkie logi z /var/log/archive/httpd. -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
On Monday, June 13, 2011 08:02:41 AM Jacek Osiecki wrote: On Sun, 5 Jun 2011, Paweł wrote: Dnia niedziela 05 czerwiec 2011, Jacek Osiecki napisał: Już drugi raz widzę coś takiego: Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i nagle zaczął siać do error_log milionami komunikatów: select() error: Invalid argument ... i tak aż do zapełnienia dysku. Apache i jego moduły (oprócz mod_php) jak najbardziej aktualny... Jakieś pomysły gdzie szukać winnych? Miałem bardzo podobne zdarzenie wczoraj wieczorem, ale raczej niezwiązane z rotacją logów. Na szczęście bylem on line i szybkie skasowanie error_log uratowało serwer przed padem. Oprócz tego apache powoli po kawałku zjada mi RAM - około 10 MB na godzinę. Nigdzie (w top ani przy spisie czynnych procesów) nie widać winnego, wszystkie forki httpd raportują po 0.5% mem, ale restart httpd zwalnia skokowo 2.5 GB z 4 GB fizycznej pamięci. Ti aktualne, apache też. Oprócz tego na Dzisiaj znowu to samo. Faktycznie nie ma nic wspólnego z rotacją logów, po prostu się zdarza i tyle. 50GB /var/log/httpd/error_log zapchane komunikatami: select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument Nikt nie ma pomysłu co to może być? ostatnio 'invalid argument' widzialem na th-x86_64 gdy na builderze byl balagan i zainstalowane byly naglowki glibc-headers.i686 co skutkowalo zlymi odwolaniami do systemu w roznych aplikacjach. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Co się stało apache'owi?
W dniu 13 czerwca 2011 08:23 użytkownik Paweł Sikora pl...@agmk.net napisał: On Monday, June 13, 2011 08:02:41 AM Jacek Osiecki wrote: On Sun, 5 Jun 2011, Paweł wrote: Dnia niedziela 05 czerwiec 2011, Jacek Osiecki napisał: Już drugi raz widzę coś takiego: Rano, najprawdopodobniej tuż po logrotate, apache zgłupiał i nagle zaczął siać do error_log milionami komunikatów: select() error: Invalid argument ... i tak aż do zapełnienia dysku. Apache i jego moduły (oprócz mod_php) jak najbardziej aktualny... Jakieś pomysły gdzie szukać winnych? Miałem bardzo podobne zdarzenie wczoraj wieczorem, ale raczej niezwiązane z rotacją logów. Na szczęście bylem on line i szybkie skasowanie error_log uratowało serwer przed padem. Oprócz tego apache powoli po kawałku zjada mi RAM - około 10 MB na godzinę. Nigdzie (w top ani przy spisie czynnych procesów) nie widać winnego, wszystkie forki httpd raportują po 0.5% mem, ale restart httpd zwalnia skokowo 2.5 GB z 4 GB fizycznej pamięci. Ti aktualne, apache też. Oprócz tego na Dzisiaj znowu to samo. Faktycznie nie ma nic wspólnego z rotacją logów, po prostu się zdarza i tyle. 50GB /var/log/httpd/error_log zapchane komunikatami: select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument select() error: Invalid argument Nikt nie ma pomysłu co to może być? ostatnio 'invalid argument' widzialem na th-x86_64 gdy na builderze byl balagan i zainstalowane byly naglowki glibc-headers.i686 co skutkowalo zlymi odwolaniami do systemu w roznych aplikacjach. Ode mnie masz jeszcze listę u mnie zainstalowanych pakietów. Może jakiś felerny moduł Ci bruździ. # rpm -qa apache-\* apr-\* |sort -u apache-base-2.2.19-1.x86_64 apache-errordocs-2.2.19-1.x86_64 apache-icons-1.0-2.noarch apache-mod_actions-2.2.19-1.x86_64 apache-mod_alias-2.2.19-1.x86_64 apache-mod_asis-2.2.19-1.x86_64 apache-mod_auth-2.2.19-1.x86_64 apache-mod_auth_basic-2.2.19-1.x86_64 apache-mod_authn_file-2.2.19-1.x86_64 apache-mod_authz_groupfile-2.2.19-1.x86_64 apache-mod_authz_host-2.2.19-1.x86_64 apache-mod_authz_user-2.2.19-1.x86_64 apache-mod_autoindex-2.2.19-1.x86_64 apache-mod_cache-2.2.19-1.x86_64 apache-mod_cern_meta-2.2.19-1.x86_64 apache-mod_cgi-2.2.19-1.x86_64 apache-mod_cgid-2.2.19-1.x86_64 apache-mod_dir-2.2.19-1.x86_64 apache-mod_env-2.2.19-1.x86_64 apache-mod_evasive-1.10.1-4.x86_64 apache-mod_fcgid-2.3.6-0.1.x86_64 apache-mod_include-2.2.19-1.x86_64 apache-mod_log_config-2.2.19-1.x86_64 apache-mod_mime-2.2.19-1.x86_64 apache-mod_mime_magic-2.2.19-1.x86_64 apache-mod_negotiation-2.2.19-1.x86_64 apache-mod_proxy-2.2.19-1.x86_64 apache-mod_rewrite-2.2.19-1.x86_64 apache-mod_setenvif-2.2.19-1.x86_64 apache-mod_speling-2.2.19-1.x86_64 apache-mod_ssl-2.2.19-1.x86_64 apache-mod_userdir-2.2.19-1.x86_64 apache-mod_version-2.2.19-1.x86_64 apache-mod_vhost_alias-2.2.19-1.x86_64 apache-suexec-2.2.19-1.x86_64 apache-tools-2.2.19-1.x86_64 apr-util-1.3.11-1.x86_64 apr-util-dbm-db-1.3.11-1.x86_64 -- I'm living proof if you do one thing right in your career, you can coast for a long time. A LONG time. -Guy Kawasaki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
