Nginx Linux

Nginx: access.log перестал записываться после ротации

  • Обновлено
  • Чтение ≈ 4 минуты
  • Нужны права администратора

Краткий ответ

После переименования или удаления журнала Nginx может продолжать писать в ранее открытый файловый дескриптор. Чтобы перейти к новому файлу, требуется штатный сигнал повторного открытия журналов, а не удаление файлов наугад.

В этой статье
  1. Что означает и когда возникает ошибка
  2. Причины и как их различить
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась

#Что означает и когда возникает ошибка

Нужно отличить неправильный путь, буферизованную запись, отключённый access_log и продолжающуюся запись в старый inode. Выявляйте причину на живом сервере без потери истории посещений и без остановки службы.

#Причины и как их различить

Возможная причинаКак узнатьЧто делать
После ротации не переоткрыт файлПроцесс держит старый дескриптор после переименования access.log.Новый файл пуст, а ротированный продолжает расти или место не освобождается.Сигнал nginx -s reopen после проверки путей и прав.
Нет права записи в новый каталог или файлРотатор создал файл с неподходящим владельцем или каталог стал недоступным.В error.log есть permission denied, файл не растёт после reopen.Восстановить владельца и права по штатной схеме, без chmod 777.
Изменён действующий access_log или применяется буферизацияЛоги перенесены в другое место, отключены директивой access_log off либо пишутся с buffer/flush.Записи приходят в другой файл или с заметной задержкой.Найти путь через nginx -T и параметры buffer/flush.

#Пошаговая диагностика и исправление

  1. Подтвердите, что журнал действительно не пополняетсяС контролируемого компьютера откройте публичную страницу сайта с уникальным безопасным параметром ?logcheck=20261102 (не вводите личные данные). Затем на сервере по SSH выполните sudo nginx -T 2>&1 | grep -n "access_log", чтобы найти действующий путь. Не исходите из того, что он обязательно /var/log/nginx/access.log: в панели хостинга путь может быть у каждого домена своим.
  2. Проверьте размер и время изменения реального файлаНайдя путь, выполните sudo ls -li /var/log/nginx/access.log и sudo tail -n 20 /var/log/nginx/access.log, заменив путь на свой. Сравните время последней строки и время теста. Если в настройке access_log off или buffer=... flush=..., учитывайте это; принудительная правка без понимания нагрузки не нужна. Если журнал пишется в syslog, просматривайте соответствующий приёмник, а не несуществующий файл.
  3. Найдите правила ротации и старый файлПосмотрите конфигурацию logrotate, обычно /etc/logrotate.d/nginx, и соседние файлы access.log.1 либо дату ротированного файла. Если новый файл пуст, а старый растёт, вероятно, Nginx не получил сигнал повторного открытия. При наличии lsof можно посмотреть открытые файлы процесса, но результаты зависят от дистрибутива и версии. Не удаляйте ротированные журналы до выяснения, кто их держит.
  4. Повторно откройте журналы штатной командойУбедитесь, что активен нужный экземпляр Nginx, и выполните по SSH sudo nginx -s reopen. Это штатный сигнал процесса, не перезапуск. Ожидается, что master и worker-процессы перейдут на новые файлы. Если команда пишет, что PID не найден, проверьте фактический путь PID и используемую конфигурацию; не угадывайте PID вручную.
  5. Проверьте права, если reopen не помогПосмотрите сообщения sudo journalctl -u nginx -n 100 --no-pager и путь error_log. Если есть Permission denied, проверьте ls -ld каталога и ls -l файла, владельца/группу процесса Nginx и штатные права после logrotate. Исправляйте только подтверждённую ошибку под контролем администратора; не используйте chmod 777 и не открывайте журнал на запись всем пользователям.
  6. Исправьте конфигурацию ротации с резервной копиейЕсли проблема повторяется каждый день, сохраните копию /etc/logrotate.d/nginx и проверьте, содержит ли postrotate штатное повторное открытие логов для вашего варианта службы. Согласуйте действие с системой управления сервером: панель может иметь собственные правила. Для проверки не запускайте logrotate с принудительным флагом на боевом сервере без понимания последствий — он может перезаписать последовательность архивов.
  7. Убедитесь в результате и сохраните архивыПовторите безопасный HTTP-запрос и сравните новую строку в текущем файле. Проверьте отсутствие новых ошибок reopen и убедитесь, что ротированный журнал больше не растёт. Если после редактирования правил появились ошибки, восстановите копию файла logrotate; при необходимости снова выполните sudo nginx -s reopen. Не удаляйте логи без утверждённого срока хранения.
  8. Дополнительная команда по теме
    Linux · Терминал (Bash)КомандаНужен sudo
    По SSH с sudo, сначала выясните активный экземпляр; команда reopen безопасно переоткрывает файлы журналов, не меняя конфигурацию.
    sudo nginx -T 2>&1 | grep -n "access_log"
    sudo nginx -s reopen
    sudo journalctl -u nginx -n 100 --no-pager

#Проверка результата

Успех: после тестового HTTP-запроса новая запись появляется в действующем access.log, ротированный файл не пополняется, ошибок прав и reopen нет.

#Если проблема осталась

Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.

Так эту ошибку тоже называют

502 502 Bad Gateway в Nginx: причины и быстрый способ найти виновника Ответ `502 Bad Gateway` означает, что Nginx, выступая шлюзом, не смог получить корректный ответ от backend-сервера — чаще всего PHP-FPM или приложения за `proxy_pass`. С… Сайты, серверы и хостинг Nginx NginxLinux Nginx: 502 Bad Gateway с PHP-FPM — причины и решение Проверьте, запущен ли php-fpm, путь к сокету и права. Сайты, серверы и хостинг Nginx Linux 504 Nginx 504 Gateway Time-out — причины и как исправить Ошибка `504 Gateway Time-out` значит, что Nginx отправил запрос приложению (PHP-FPM, Node.js, другому серверу), но не дождался ответа за отведённое время. Чаще всего при… Сайты, серверы и хостинг Nginx NginxLinuxPHP-FPM Nginx: ERR_TOO_MANY_REDIRECTS — цикл редиректов http/https и www — причины и решение Найдите петлю редиректов в конфиге и CMS, проверьте Cloudflare и proxy. Сайты, серверы и хостинг Nginx Linux 504 Nginx: 504 Gateway Time-out — upstream не отвечает вовремя — причины и решение Nginx выдаёт 504 Gateway Time-out, когда backend (PHP-FPM, Node.js, прокси) не успевает ответить за отведённое время. Увеличьте proxy_read_timeout или fastcgi_read_timeo… Сайты, серверы и хостинг Nginx Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.