34. Что делать, когда падает Apache (или другой сервер) в Unix

[17 сентября 2003 г.]

обсудить статью в форуме

Если ну совсем уж ничего не получается, прочти, наконец, инструкцию! Народная мудрость.

Набла была написана, т.к. по данному конкретному вопросу в Интернете довольно мало практических рекомендаций. Имеется лишь море теории и огромные залежи документации, а практических советов почти нет. К сожалению, это частый случай в мире Unix.

Что вы делаете, когда в Windows возникает окно «Программа выполнила недопустимую операцию и будет закрыта»? Тихо материтесь и запускаете ее опять. А что, если это — программа «электронный кошелек» для работы с WebMoney, и она вылетает снова и снова, как раз после того, как вам пришел крупный денежный перевод? Материтесь и перезапускаете ее, пока ваш словарный запас мата не исчерпается. Отдаляя, между прочим, шанс заполучить денежки. В перерывах можно перезагружать компьютер до отказа Reset-а, а толку?..

Что же делать, если вдруг начал «падать» один из серверов в Unix и «обычные» средства не помогают?..

Ехал «новый русский», и вдруг у него сломалась машина. Остановился он, смотрит, как баран на новые ворота. Мимо проезжает второй «кореш», останавливается. — Что, братан, машина сломалась? — Ага... — Э, друг, да тебе повезло, я в этом деле спец! — Правда?.. И что делать? — Ну, ты ногой по баллону постучи. — Уже стучал, не помогает. — Ну, а стекло ветровое протирал? — Протирал. — Ну, блин... Тогда я не знаю...

Между тем, есть реальный шанс все поправить, и, как ни странно, это не так уж и сложно. Как всегда, шанс дан только тем, кто хорошо знает Си, остальные могут даже и не беспокоиться — впрочем, они вряд ли заметят, что у них что-то упало (из серверов, естественно).

Для простоты предположим, что мы имеем дело с Apache (в дальнейшем — просто сервер). Симптомы следующие: программа периодически «падает», а в ее основной директории (или еще где-то, ищите) остается файл core с каким-то там дампом — мусор, в общем. Так что поработаем-ка мусорщиками.

Компиляция в отладочном режиме

Прежде, чем рвать на себе волосы, внимательно посмотрите, что пишется в логах сервера. Убедитесь, что Apache действительно «падает» и при этом создается core-файл. Вам следует точно определиться, необходимо ли пользоваться советами, приведенными далее, или же удастся без них обойтись. Незачем стрелять из пушки по воробьям.

Вначале надо убедиться, что сервер собран из исходников. (Если он был установлен уже откомпилированным, то вам в морг, в морг.) Когда кто-то хочет выжать максимальную надежность из той или иной программы в Unix, он компилирует ее вручную. Во-первых, так доступно больше возможностей по настройке. Во-вторых, всегда можно поправить то, что не нравится — обычно разбираться в коде не так уж и сложно. Наконец, в-третьих, если программа «упадет», можно будет понять по исходникам, из-за чего это произошло — читайте дальше.

Далее идет очень важный момент. Убедитесь, что вы собираете программу со включенной отладочной информацией. Это несколько увеличивает размер исполняемых файлов, зато позволяет определить, что произошло с зависшим или упавшим сервером, не прибегая к помощи чукотского шамана.

Для включения отладочного режима существует ключ -g у gcc — компилятора Си. Он обычно указывается в файлах Makefile, там, где задаются флаги компилятора. Например, посмотрим на первые строчки src/Makefile от Apache:

скопировать код в буфер обмена Листинг 1

## ## Apache Makefile, automatically generated by ## Configure script. Hand-edited changes will be ## lost if the Configure script is re-run. ## Sources: - ./Makefile.config (via Configuration.apaci) ## - ./Makefile.tmpl ## я тут пропустил пару строк ## ## Inherited Makefile options from Configure script ## (Begin of automatically generated section) ## SRCDIR=. EXTRA_CFLAGS=-DRECORD_FORWARD `\$(SRCDIR)/apaci` EXTRA_LDFLAGS=

Видите переменную EXTRA_CFLAGS? Вы найдете ее и в большинстве других make-файлов. Нетрудно догадаться, что в ней задаются дополнительные флаги, учитывающиеся при компиляции.

Но подождите править! Прочтите же то, что написано сверху. А там говорится, что при следующем запуске Configure все ваши изменения потеряются. Честно говоря, разматывать все зависимости между скриптами-конфигураторами совершенно не хочется, а потому воспользуемся Гуглом, запросом apache debug gcc "-g" и первой же найденной статьей на эту тему, слегка подкорректировав советы в ней.

Вкратце, чтобы сконфигурировать Apache (да и большинство других программ, в исходниках которых есть скрипт configure) в отладочном режиме, воспользуйтесь командой:

(CFLAGS='-g'; export CFLAGS; ./configure параметры)

Обязательно используйте скобки (так, как написано выше), иначе переменная CFLAGS «прилипнет» к текущему окружению, и любые программы будут ее видеть даже тогда, когда вы явно ее не проставляете (так работает команда export). Если же не использовать export, то в bash скрипт configure почему-то переменную не видит.

Потом, как обычно, make и make install.

Работа с отладчиком GDB

Дальше начинается самое интересное. Будем считать, что у нас «глючит» Apache, установленный в директорию /usr/local/apache — при падении создается файл core в этой директории.

Устанавливаем отладчик GNU Debugger (в простонародье — GDB). Поищите в Гугле, скачайте и установите самую новую версию, если ее у вас еще нет. Если у вас Linux, можете взять отладчик в виде RPM-пакета, это даже проще.

Подробная документация GDB на русском языке есть по адресу http://www.opennet.ru/docs/RUS/gdb/gdb_toc.html.

Вначале останавливаем сервер (иначе core может затереться). Затем переходим в директорию /usr/local/apache и создаем там файл (например, gdb.cmd), в котором укажем директории с исходниками Apache. Иначе GDB не сможет работать в режиме просмотра исходников. Пример файла gdb.cmd:

скопировать код в буфер обмена Листинг 2

directory /usr/src/apache/src directory /usr/src/apache/src/modules directory /usr/src/apache/src/modules/standard directory /usr/src/apache/src/modules/extra

В общем, чем больше там директорий, тем лучше. Ну а дальше запускаем команду:

скопировать код в буфер обмена Листинг 3

gdb -x gdb.cmd ./bin/httpd ./core

Это заставляет GDB исследовать файл ./core, загрузив предварительно исполняемый файл ./bin/httpd в память.

GDB автоматически останавливается в том месте, где произошла ошибка и был создан файл core. Поэтому набираем bt, чтобы вывести на экран стек вызовов функций. Таким образом, сразу видно, в какой подпрограмме возникла проблема.

Чтобы показать исходный код программы в текущем месте, набираем list. Печатается текущая строчка, обрамленная несколькими предыдущими и следующими строками программы.

Если нас интересует значение какой-нибудь переменной (локальной или глобальной) в программе, мы можем его вывести при помощи команды print имя_переменной. Удобно то, что GDB позволяет печатать значения не только простых переменных, но и структур, массивов и т. д. Можно даже вычислить какое-нибудь выражение, составленное по правилам языка Си.

Наконец, можно «путешествовать» по дереву вызовов функций, делая текущей то одну, то другую. Для этого существуют, соответственно, команды up (вверх по дереву до конечной функции) и down (вниз по дереву в сторону вызывающей функции).

Для выхода из отладчика введите команду q, а для просмотра помощи по командам — help.

Определение причины «зависания» программы

Теперь, когда вы поняли, что не так все и сложно, буду краток. Если некоторый сервер «завис», вы можете посмотреть, в каком месте программы он в данный момент «крутится». Для этого используется команда:

скопировать код в буфер обмена Листинг 4

gdb bin/httpd 1234

Здесь bin/httpd — как обычно, путь к исполняемому файлу, а 1234 — идентификатор процесса (PID), который «завис». Дальше можно пользоваться командами: next (выполнить следующую команду), step (выполнить следующую команду и, возможно, войти внутрь функции), break file:func (установить точку останова внутри функции func, расположенной в файле file) и, наконец, c (продолжить выполнение до следующей точки останова).

Подробности, а также описание других полезных команд, читайте в документации GDB или по адресу http://www.opennet.ru/docs/RUS/gdb/gdb_toc.html.

Краткая сводка полезных команд GDB

bt

Вывод стека вызовов на момент ошибки, очень удобно!

up

Сделать текущим предыдущий фрейм вызова функции.

down

Сделать текущим следующий фрейм.

list

Показать ИСХОДНЫЙ КОД в текущем месте.

print expr

Печать значения выражения expr. Выражение пишется НА СИ, можно просматривать даже структуры целиком, использовать имена переменных и т. д.

q

Выход из отладчика.

help

Вывод справки по категориям команд. Напоминаю, что подробная документация есть по адресу http://www.opennet.ru/docs/RUS/gdb/gdb_toc.html.

next

Выполнить следующую команду.

step

Выполнить следующую команду и, возможно, войти внутрь функции.

break file:func

Установить точку останова внутри функции func, расположенной в файле file. Если вызвана без параметров, устанавливает точку останова в текущем месте.

c

Продолжить выполнение до следующей точки останова.

Распространенные ошибки

Если однажды GDB по команде list вместо строчки из программы выведет какую-нибудь белиберду (обычно там идет речь про какой-то eval.c), не отчаивайтесь. Возможные причины ошибки:

• Вы забыли какую-то из директорий с исходниками. Чтобы учесть их все, воспользуйтесь, например, такой командой:

  скопировать код в буфер обмена Листинг 5

  find /usr/src/apache -name Makefile

  Я, например, написал для себя следующий скрипт запуска GDB — он сам определяет нужные директории:

  # http://www.opennet.ru/docs/RUS/gdb/gdb_toc.html
  BIN=bin/httpd
  ROOT=/usr/src/apache
  CONFIG=gdb.cnf.auto
  find $ROOT -name Makefile \
       -printf "directory %h\n" > $CONFIG
  gdb -x $CONFIG $BIN core
  rm -f $CONFIG

• Вы не откомпилировали тот или иной модуль в отладочном режиме. Проверьте, использовался ли ключ -g при его компиляции — исследуйте вывод команды make.
• Возможно, проблема в действительности в PHP (если он у вас установлен в виде модуля), а вовсе даже и не в Apache. Так что вам также придется откомпилировать в отладочном режиме и PHP.

обсудить статью в форуме