Неожиданно начал падать apache

[Drakon]

Несколько месяцев сервер на VPS РБК-хостинга нормально работал, никаких изменений не вносилось... Вчера у apache начали появляться segmentation fault:

[Sun Dec 26 22:30:21 2010] [notice] child pid 9955 exit signal Segmentation fault (11)
[Sun Dec 26 22:30:21 2010] [notice] child pid 9957 exit signal Segmentation fault (11)
*** glibc detected *** /usr/sbin/apache2: malloc(): memory corruption: 0x0a3ab318 ***
*** glibc detected *** /usr/sbin/apache2: malloc(): memory corruption: 0x0a158e90 ***
*** glibc detected *** /usr/sbin/apache2: double free or corruption (out): 0x0a3482a8 ***

И иногда вот такие (про libxml и libphp):

[Sun Dec 26 21:09:56 2010] [notice] Apache/2.2.16 (Unix) configured -- resuming normal operations
[Sun Dec 26 21:09:57 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting
*** glibc detected *** /usr/sbin/apache2: malloc(): memory corruption: 0x0afa44a0 ***
[Sun Dec 26 21:19:20 2010] [notice] child pid 5690 exit signal Segmentation fault (11)
[Sun Dec 26 21:23:50 2010] [notice] child pid 5691 exit signal Segmentation fault (11)
*** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x0a2061a0 ***
======= Backtrace: =========
/lib/libc.so.6[0x326af0]
/usr/lib/libxml2.so.2(xmlFreeNodeList+0x1df)[0x7367673]
======= Memory map: ========
00110000-00134000 r-xp 00000000 08:04 21153380   /lib/libm-2.10.1.so
00134000-00135000 r--p 00023000 08:04 21153380   /lib/libm-2.10.1.so
00135000-00136000 rw-p 00024000 08:04 21153380   /lib/libm-2.10.1.so
00136000-0024e000 r-xp 00000000 08:04 20911396   /usr/lib/libdb-4.5.so
0024e000-00250000 r--p 00117000 08:04 20911396   /usr/lib/libdb-4.5.so
00250000-00252000 rw-p 00119000 08:04 20911396   /usr/lib/libdb-4.5.so
00252000-0026f000 r-xp 00000000 08:04 20913739   /usr/lib/libexpat.so.1.5.2
0026f000-00271000 r--p 0001d000 08:04 20913739   /usr/lib/libexpat.so.1.5.2
00271000-00272000 rw-p 0001f000 08:04 20913739   /usr/lib/libexpat.so.1.5.2
00272000-00274000 r-xp 00000000 08:04 20927905   /usr/lib/apache2/modules/mod_auth_basic.so
00274000-00275000 r--p 00001000 08:04 20927905   /usr/lib/apache2/modules/mod_auth_basic.so
00275000-00276000 rw-p 00002000 08:04 20927905   /usr/lib/apache2/modules/mod_auth_basic.so
....................

С чем может быть связано?

 

[tony2001]

Версия PHP?

Апач тут не причем, конечно. А для того, чтобы баг проявился, необязательно что-то самому менять, достаточно, чтобы поменялись входящие данные.
Я бы рекомендовал обновить для начала PHP, с вероятностью 99% это исправлено в последней стабильной версии.

 

[Drakon]

Обновился.
Теперь такая конфигурация:
glibc 2.10.1-r1
libxml 2.7.7
apache 2.2.16
php 5.3.4
Все PECL-модули отключил на всякий случай.

Ошибки всё равно продолжаются.

 

[Активист]

> memory corruption: 0x0afa44a0
Вам не кажется щито вашему железу пришел конец?
Я такой ошибки не видел, но слово memory corruption (память повреждена по адресу) ) не сложно догодаться.
MEM Test вам в помощь (а еще kern.log)

 

[Активист]

Хотя сюда по гуглу - проблема встречатеся часть, проверьте память, если с ней все впорядке, баг репорт.

 

[Drakon]

Это VPS-сервер. Может какие-то проблемы у виртуальной машины с выделением памяти? Но почему тогда система не падает целиком?

 

[Активист]

Ну а что твоя тех поддержка сказала?

 

[Drakon]

Написал им ещё вчера. Пока молчат.

 

[tony2001]

>Вам не кажется щито вашему железу пришел конец?
>Я такой ошибки не видел
Зато я видел. Железо к ней никоим боком не относится.

Drakon, можешь выделить кусок кода, который это вызывает?

 

[Drakon]

Код пока не пробовал выделять.
Щас чел увидел моё сообщение на форуме - отписал в аську, что у него на VDS РБК такая же проблема. Походу в хостинге дело... Попробую пока ещё на нескольких форумах поднять тему, где люди из РБК есть и буду ковырять код.
Техподдержка пока молчит.

 

[tony2001]

*sigh*
ну причем тут хостинг, апач, зеленые человечки и тоталитаризм в отдельно взятой банановой республике?
падает некий программный продукт у тебя, неужели не очевидно, что только он и может быть виноват?
что это за OS? какая полная версия PHP? (покажи полный вывод `php -v`).

а техподдержка доставляет, да.

 

[Drakon]

# php -v
PHP 5.3.4-pl0-gentoo (cli) (built: Dec 26 2010 22:01:24) 
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

# uname -a
Linux HOST 2.6.18-194.3.1.el5.028stab069.6 #1 SMP Tue Jun 1 01:33:39 MDT 2010 i686 Intel(R) Xeon(R) CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux

 

[Drakon]

Вообщем попробовал сделать лог-файл, в который записывался бы ID процесса, обрабатывающего HTTP-запрос + сам запрос. Дождался после этого, когда упадёт апач. Просмотрел в логе все запросы, которые были сделаны к упавшему процессу... Попробовал их выполнить - ничего не упало.
Есть подозрение, что память постепенно "портится" каким-то кодом и процесс падает после серии запросов.
И что теперь делать?
Вариант пока вижу только 1 - сделать, чтоб все запросы обрабатывал только 1 процесс. Дождаться пока он упадёт и попробовать выполнить снова все эти запросы. Тогда хотябы понятно будет, существует-ли такая серия запросов, которая кладёт апач.

 

[Drakon]

Выделил серию запросов, на одном процессе. Запустил её снова - не хочет падать процесс.
Что теперь делать-то?

 

[tony2001]

>Есть подозрение, что память постепенно "портится" каким-то кодом и процесс падает после серии запросов.
да, это вполне реально.

>И что теперь делать?
есть возможность пересобрать PHP с --enable-debug?
если да, то пересобери и http://bugs.php.net/bugs-generating-backtrace.php
бэктрэйс даст чуть больше информации.
но всё равно очень хотелось бы иметь не только его, но и код.

 

[tony2001]

было бы еще очень неплохо попробовать поставить последний снапшот 5.3 - http://snaps.php.net
и дальше уже танцевать от того, воспроизводится ли проблема на нём или нет.

 

[Drakon]

Скачал PHP-снапшот: php5.3-201012280930
Собрал его:
./configure --prefix=/root/phpdebug --enable-debug --with-apxs2 --with-zlib --with-gd --with-mhash --enable-mbstring --with-mcrypt --with-mysql --enable-sockets --with-xmlrpc --with-xsl --enable-zip
Подложил новый модуль апачу, перезапустил апач с 1 prefork процессом. Итого в системе было 2 процесса.
Посмотрел в логах, какой процесс обрабатывает запросы: 20244.
Приаттачился к нему gnu-debugger'ом.
Дождался пока упадёт и получилось что-то непонятное:

http://www.mos-catalog.ru/common/debug/gdb1.txt

 

[craz]

по-моему все более чем понятно вас уже давно просят код где это все у вас валиться!!!

 

[Drakon]

Ну судя по тому, что выдаёт gdb - проблема в libc... Или я неправильно понял?

 

[craz]

Ну судя по тому, что выдаёт gdb - проблема в libc... Или я неправильно понял?

Loaded symbols for /usr/lib/libcrypto.so.0.9.8
0x0041f8d2 in ?? () from /lib/ld-linux.so.2
(gdb) cont
Continuing.

судя по этому... нет. Что-то раняет у вас апач и это что-то у вас в коде. Но видимо вы сами не умеете дебажить(хотя вроде нормально разбираетесь в администрировании), а нам не даете даже посмотреть код...

Я могу ошибаться конечно