В чем может быть причина не создания Log файлов, если на диске есть место

Диагностика проблемы с отсутствием создания лог-файлов

Основная причина, когда лог-файлы не создаются, несмотря на наличие свободного места на диске, обычно связана не с дисковым пространством, а с правами доступа, конфигурацией приложения или системными ограничениями. Место на диске — лишь один из многих факторов, и его наличие не гарантирует работоспособность логирования. Вот детальный разбор возможных причин и методов диагностики.

Основные категории причин

1. Проблемы с правами доступа и владельцем

Самая частая причина. Процесс (демон или пользовательское приложение) не имеет прав на запись в целевую директорию.

• Недостаточные права на директорию: Директория, в которую должны писаться логи, может иметь права drwxr-xr-x (только чтение и выполнение для группы/остальных), а процесс работает от пользователя, не являющегося владельцем.
• Неправильный владелец: Директория или родительские директории принадлежат другому пользователю (например, root), а приложение запущено от непривилегированного пользователя.
• SELinux / AppArmor: На системах с обязательным контролем доступа (SELinux в RHEL/CentOS, AppArmor в Ubuntu) могут блокироваться операции записи, даже если классические права Unix в порядке.

Диагностика:

# Проверяем права и владельца целевой директории
ls -la /var/log/myapp/

# Проверяем, от какого пользователя/группы работает процесс
ps aux | grep [n]ame_of_your_app
# или, если это системный демон
systemctl status your-service --no-pager | grep "Main PID"
# Для PID из вывода выше:
ps -o user,group -p <PID>

# Проверяем контекст SELinux (если применимо)
ls -Z /var/log/myapp/
ps auxZ | grep [n]ame_of_your_app
# Проверяем аудит лог SELinux на наличие denied
sudo ausearch -m avc -ts recent

2. Ошибки в конфигурации приложения или демона

• Неправильный путь к лог-файлу: В конфигурационном файле (log4j.properties, logback.xml, syslog, rsyslog.conf, journald.conf, настройках самого приложения) указан ошибочный или несуществующий путь. Например, относительный путь, который интерпретируется относительно неожиданной рабочей директории.
• Конфигурация с буферизацией или асинхронной записью: Некоторые логгеры (например, log4j2 с AsyncAppender) могут буферизировать логи в памяти, и при аварийном завершении приложения логи могут быть потеряны, создавая иллюзию их отсутствия.
• Уровень логирования (Log Level): Установлен слишком высокий уровень фильтрации (например, ERROR или FATAL), и информационные события (INFO, DEBUG) просто не записываются.

Диагностика:

# Ищем конфигурационные файлы
sudo find /etc -name "*log*" -type f | grep -i your_app_name
sudo find /opt -name "*log*" -type f 2>/dev/null

# Смотрим конфигурацию системного демона (на примере systemd)
sudo systemctl cat your-service
# Особое внимание на строки StandardOutput= и StandardError= (они могут перенаправляться в journald)
# Проверяем журнал systemd на наличие ошибок от сервиса
sudo journalctl -u your-service -n 50 --no-pager

3. Системные ограничения и ресурсы

• Inode exhaustion: На диске может быть свободное место, но исчерпаны inodes (индексы файловых дескрипторов). Файловая система не может создать новый файл, даже если есть свободные блоки данных.
• Достигнут лимит открытых файлов (file descriptors): Для процесса или системы в целом может быть достигнут лимит, что препятствует открытию нового файла для записи.
• Диск или файловая система в режиме read-only: Такое может произойти из-за ошибок ФС, проблем с hardware или действий администратора. Запись невозможна.

Диагностика:

# Проверяем использование inodes
df -i /path/to/log/directory

# Проверяем лимиты для текущей оболочки или процесса
ulimit -n # для оболочки
# Для запущенного процесса по PID
cat /proc/<PID>/limits | grep "open files"

# Проверяем, не смонтирована ли ФС в read-only
mount | grep " /var/log"
# Или для корня
findmnt -O ro

4. Особенности системного логирования (systemd, syslog)

• Перенаправление в systemd journal: Многие современные дистрибутивы по умолчанию используют systemd, и демоны пишут логи не в файлы, а в журнал systemd (journald). Лог-файлы в /var/log/ могут не создаваться, если это не настроено явно через rsyslog или syslog-ng.
• Ошибки конфигурации rsyslog/syslog-ng: Правила фильтрации могут отбрасывать сообщения от вашего приложения.
• Остановлена или не работает служба логирования: Служба rsyslog или journald может быть в состоянии failed.

Диагностика:

# Проверяем, куда пишет демон через systemd
sudo systemctl status your-service
# Если в статусе видим журнал, читаем его
sudo journalctl -u your-service -f

# Проверяем статус службы системного логирования
sudo systemctl status rsyslog journald

Общий алгоритм диагностики

1. Определите целевой процесс: Узнайте PID и пользователя процесса, который должен логировать.
2. Проверьте конфигурацию: Изучите конфигурационные файлы приложения и системных демонов (systemd unit файлы, rsyslog.conf).
3. Убедитесь в правах доступа: Проверьте ls -la для целевой директории и всех родительских директорий до корня. Проверьте SELinux/AppArmor.
4. Проверьте системные ресурсы: Выполните df -i и ulimit проверки.
5. Изучите альтернативные места хранения логов: Используйте journalctl, проверьте стандартные потоки вывода (stdout/stderr) процесса, которые могли быть перенаправлены.
6. Упростите тест: Попробуйте запустить приложение вручную от того же пользователя с минимальной конфигурацией и с записью лога в простую локацию (например, /tmp/test.log), чтобы исключить комплексные факторы.

Отсутствие логов при свободном диске — это почти всегда проблема конфигурации, прав или архитектуры логирования в вашем окружении.