Системное администрирование

Как посмотреть журналы ошибок Apache2

Как посмотреть журналы ошибок Apache2

Журналы ошибок Apache2 — первое место, куда я отправляю любого, кто столкнулся с непонятным поведением сайта. Будь то 500-я ошибка, криво отработавший виртуальный хост или просто белый экран вместо страницы — Apache почти всегда оставляет след в error log. На Ubuntu и Debian по умолчанию этот файл лежит в /var/log/apache2/error.log, но если сервер настраивали до вас, путь мог измениться. Поэтому перед тем как листать лог, всегда проверяйте конфигурацию — сэкономите кучу времени.

Зачем вообще смотреть error log Apache2

Журнал ошибок даёт не просто факт «что-то пошло не так», а конкретику: на каком уровне возникла проблема и куда копать дальше. Вот типичные сценарии, с которыми я сталкивался в техцентре:

  • опечатка или логическая ошибка в конфигурационном файле Apache;
  • битый .htaccess — одна пропущенная скобка может положить весь сайт;
  • недостаточно прав на каталог или файл, особенно после переноса проекта между серверами;
  • сбой в связке с PHP-FPM: процесс упал, не отвечает или не может найти скрипт;
  • неправильно настроенный виртуальный хост — сайт молчит, а в логе чётко написано, какой именно;
  • внутренние ошибки самого приложения, которые Apache перехватывает и логирует.

Главная ценность error log в том, что Apache пишет не просто «ошибка», а полный контекст: путь к проблемному файлу, строку конфигурации, имя виртуального хоста, PID процесса и уровень сообщения. Новички часто грешат тем, что смотрят access log, а там только строчки с кодами ответа — и никакого объяснения. Не повторяйте эту ошибку: access log показывает, что запросили, а error log — почему это не сработало.

Где находится журнал ошибок Apache2 в Ubuntu

В Ubuntu и других Debian-подобных системах стандартный путь такой:

/var/log/apache2/error.log

Но если сайтов несколько и для каждого настроен отдельный виртуальный хост, логи могут быть разнесены. В таких случаях смотрите директиву ErrorLog внутри конкретного хоста — именно она определяет, куда пишутся ошибки этого сайта.

Что ещё может встретиться

Сценарий Где искать
Стандартная установка Ubuntu/Debian /var/log/apache2/error.log
Отдельный виртуальный хост путь из директивы ErrorLog
Альтернативная схема логирования файлы в /var/log/apache2/ или путь, заданный вручную

Если вы только начинаете разбираться с сервером, запомните: в Ubuntu почти всегда всё крутится вокруг /var/log/apache2/. Но как только появляется кастомизация — пути могут уйти куда угодно, поэтому всегда проверяйте конфиги.

Как посмотреть журнал ошибок Apache2

1. Посмотреть последние строки

Самый быстрый способ оценить обстановку — вывести хвост файла. Обычно хватает 50 последних строк, но если ошибка произошла раньше, увеличьте число:

sudo tail -n 50 /var/log/apache2/error.log

Это удобно сразу после перезапуска Apache или правки конфигурации: все свежие сообщения перед глазами.

2. Смотреть лог в реальном времени

Когда ошибка воспроизводится прямо сейчас, используйте непрерывный просмотр. Я предпочитаю tail -F (с большой F) вместо -f — он отслеживает файл по имени и не теряет его при ротации. На боевых серверах логи часто переименовываются, и обычный tail -f может «зависнуть», показывая старый дескриптор:

sudo tail -F /var/log/apache2/error.log

Теперь открывайте сайт, вызывайте проблемную страницу и сразу видите, что пишет Apache.

3. Искать по ключевым словам

Если лог разросся до десятков мегабайт, листать его вручную неудобно. Фильтруйте по ключевым словам: PHP, права доступа, имя виртуального хоста. grep с флагом -i игнорирует регистр, что часто спасает:

sudo grep -i "php" /var/log/apache2/error.log
sudo grep -i "permission denied" /var/log/apache2/error.log

Можно комбинировать с tail -f для live-фильтрации:

sudo tail -F /var/log/apache2/error.log | grep -i "error"

Только помните: если ошибок много, такой пайп может тормозить вывод — тогда лучше сначала сохранить кусок лога в отдельный файл и анализировать его.

Как понять, что именно искать в логе

Apache маркирует сообщения уровнями. На практике важны такие:

  • warn — предупреждение, которое пока не роняет сервер, но сигнализирует о потенциальной проблеме;
  • error — реальная ошибка, из-за которой запрос не обработался;
  • crit, alert, emerg — серьёзные сбои, требующие немедленного вмешательства (например, нехватка памяти или падение дочернего процесса).

В Ubuntu уровень логирования задаётся директивой LogLevel. По умолчанию стоит warn, поэтому отладочные сообщения вы не увидите. Если нужно больше деталей, можно временно поднять до debug, но на боевом сервере так не работают — лог моментально забивается мусором. Лучше точечно повышать уровень только для нужного модуля, например: LogLevel debug mod_rewrite.c.

Типичные сообщения и что они значат

Сообщение в логе Что это обычно означает
Permission denied нет доступа к файлу, каталогу или сокету; часто всплывает при проблемах с правами на /var/run/php или DocumentRoot
File does not exist Apache не нашёл запрошенный путь — проверьте, правильно ли собран DocumentRoot и нет ли опечаток в URL
AH00035 / AH00558 проблема с конфигурацией или невозможностью определить полное доменное имя сервера; обычно лечится добавлением ServerName в основной конфиг
client denied by server configuration доступ запрещён правилами Apache — смотрите Require, Deny и ограничения в .htaccess
Primary script unknown проблема на стороне PHP-FPM или путь к скрипту указан неверно; проверьте, что файл существует и доступен для чтения пользователем, от которого работает PHP

Эти записи редко говорят «всё пропало», но почти всегда дают направление для поиска. Если видите AH00035, не пугайтесь — это классика, когда сервер не может определить свой FQDN, и на работу сайта часто не влияет, но лучше исправить.

Где искать путь к логам, если /var/log/apache2/error.log не подходит

Если стандартный файл пуст или отсутствует, первым делом проверьте конфигурацию Apache. В Ubuntu удобно грепать по всем файлам в /etc/apache2/:

sudo grep -r "ErrorLog" /etc/apache2/

Ещё быстрее — посмотреть сводку виртуальных хостов с путями к логам через apache2ctl -S (или httpd -S на CentOS). Эта команда выводит все настроенные хосты и их ключевые параметры, включая расположение error log.

Пример директивы из типового виртуального хоста Ubuntu:

ErrorLog ${APACHE_LOG_DIR}/error.log

Переменная APACHE_LOG_DIR обычно указывает на /var/log/apache2, но её могут переопределить. Поэтому, если видите такую конструкцию, проверьте, чему равна переменная в /etc/apache2/envvars.

Как смотреть отдельный лог сайта

Когда на сервере несколько сайтов, общий error log превращается в кашу. Гораздо удобнее развести логи по разным файлам — так вы сразу поймёте, какой именно проект сыпет ошибками. В конфигурации виртуального хоста пропишите:

ErrorLog /var/log/apache2/site1-error.log

Не забудьте после этого настроить ротацию логов через logrotate, иначе через пару месяцев диск забьётся под завязку. Для каждого отдельного файла нужно создать правило в /etc/logrotate.d/, иначе Apache будет писать бесконечно.

Полезный порядок диагностики

Когда сайт не открывается или отдаёт ошибку, действуйте последовательно — это сэкономит нервы и время:

  1. Убедитесь, что Apache вообще жив: sudo systemctl status apache2 (или service apache2 status). Если он остановлен, никакие логи ошибок не помогут.
  2. Откройте свежие ошибки: sudo tail -n 50 /var/log/apache2/error.log — часто причина видна сразу.
  3. Посмотрите конфигурацию проблемного виртуального хоста: sudo apache2ctl -S или напрямую файл в /etc/apache2/sites-enabled/.
  4. Проверьте синтаксис конфигурации: sudo apache2ctl configtest. Это обязательно перед перезапуском, иначе можно положить сервер.
  5. Если ошибка связана с PHP, загляните в системный журнал: sudo journalctl -u apache2 --since "5 minutes ago" или sudo tail /var/log/syslog. Иногда PHP-FPM пишет свои ошибки в /var/log/php*-fpm.log или в тот же syslog.

Такой порядок помогает не метаться между десятком файлов, а планомерно сужать круг подозреваемых.

Частые ошибки новичков

  • Ищут проблему только в браузере. Браузер показывает общую ошибку 500, а детали — только в логах. Не тратьте время на гадание, сразу открывайте error log.
  • Смотрят не тот файл. Access log фиксирует запросы, но не объясняет, почему они не отработали. Ошибки конфигурации, прав доступа и кодов приложения — всё в error log.
  • Забывают, что виртуальный хост может писать в отдельный журнал. Если сайтов несколько, а вы смотрите общий лог, можно пропустить ошибку конкретного проекта.
  • Не проверяют права на файлы и каталоги. Apache работает от пользователя www-data, и если владелец или права не позволяют читать файл, в логе будет Permission denied.
  • Читают старые записи и не замечают свежие ошибки после перезапуска. После правки конфигурации обязательно смотрите последние строки, а не листайте лог с начала.
  • Меняют конфиг, но не делают configtest. Одна пропущенная точка с запятой — и Apache не стартует. Проверка синтаксиса занимает секунду, а спасает от долгих минут простоя.

Мини-чек-лист для быстрой проверки

  • Открылся ли нужный файл лога (проверьте права на сам лог — иногда он недоступен для чтения).
  • Совпадает ли путь с ErrorLog в конфигурации виртуального хоста.
  • Есть ли свежие строки после повторения ошибки (сравните временные метки).
  • Не указывает ли лог на права доступа — если да, проверьте владельца и chmod.
  • Не сломан ли синтаксис Apache — выполните configtest.
  • Не пишет ли проблема в лог другого виртуального хоста — возможно, вы смотрите не тот файл.

Если лог пустой или почти пустой

Такое бывает, когда запросы вообще не доходят до Apache — например, проблема на уровне сети или балансировщика. Другие причины:

  • ошибка находится в другом компоненте (PHP-FPM, база данных), и Apache не считает её своей;
  • лог перенесён в другое место через директиву ErrorLog;
  • уровень логирования слишком низкий — стоит crit или выше, а ошибки имеют уровень error;
  • Apache ещё не перезапускался после изменения конфигурации, и новые настройки не применились.

В такой ситуации проверьте ErrorLog и LogLevel в конфигурации, а также системный журнал службы Apache: sudo journalctl -u apache2. Иногда ошибки старта самого сервера попадают именно туда, а не в error log.

Коротко: что делать на практике

Если нужно быстро понять, что с сайтом, используйте связку из трёх команд:

sudo tail -n 50 /var/log/apache2/error.log
sudo tail -F /var/log/apache2/error.log
sudo grep -i "error" /var/log/apache2/error.log

Если лог не там, где ожидается, найдите реальный путь через grep -r "ErrorLog" /etc/apache2/ или apache2ctl -S. На Ubuntu это особенно важно, потому что разные виртуальные хосты могут писать в разные файлы, и общий лог может молчать.

FAQ

Какой файл чаще всего используется для ошибок Apache2 в Ubuntu?

В подавляющем большинстве случаев это /var/log/apache2/error.log. Если вы не настраивали отдельные логи для виртуальных хостов, все ошибки сыплются именно туда.

Чем error log отличается от access log?

Error log — это журнал проблем: сбои конфигурации, ошибки скриптов, нехватка прав. Access log — журнал посетителей: кто, когда и какую страницу запросил, с каким кодом ответа. Если сайт не работает, сначала смотрите error log, а access log пригодится для анализа трафика.

Как посмотреть ошибки Apache в реальном времени?

Используйте sudo tail -F /var/log/apache2/error.log. Флаг -F надёжнее, чем -f, потому что отслеживает файл по имени и не теряет его при ротации.

Что делать, если логов слишком много?

Сначала отфильтруйте их по ключевым словам через grep, например, по имени виртуального хоста или типу ошибки. Если это не помогает, проверьте отдельный лог нужного сайта — скорее всего, для него настроен свой файл, и шум создают другие проекты.

Как понять, где Apache пишет ошибки именно моего сайта?

Посмотрите директиву ErrorLog в конфигурации виртуального хоста. Быстрый способ — выполнить sudo apache2ctl -S и найти ваш сайт в выводе, там будет указан путь к логу ошибок. Либо просто грепните по /etc/apache2/: sudo grep -r "ErrorLog" /etc/apache2/.

Вывод

Чтобы посмотреть журналы ошибок Apache2, в девяти случаях из десяти достаточно открыть /var/log/apache2/error.log и просмотреть свежие строки через tail. Если стандартный путь не подходит, ищите директиву ErrorLog в конфигурации — именно она показывает реальное место записи журнала.

Для повседневной работы держите в голове три команды: tail -n 50 для быстрого осмотра, tail -F для live-мониторинга и grep для фильтрации. Этого арсенала хватает, чтобы найти причину большинства проблем с Apache на Ubuntu. А если копнуть глубже — понимание структуры логов и контекста ошибок превращает хаотичный дебаг в понятный и предсказуемый процесс.