MongoDB в systemd: почему mongod не поднимается
MongoDB под systemd падает по трём основным причинам: права на каталог данных, остатки файла блокировки после аварийного завершения и ошибки в файле настроек, который у неё в формате YAML и чувствителен к отступам.
О службе
Каталог данных (обычно /var/lib/mongodb) должен принадлежать пользователю mongodb целиком. После восстановления из копии под root служба не стартует, и в журнале видно сообщение об отказе доступа к файлам базы.
Второй частый случай — аварийное завершение. MongoDB держит файл блокировки, и при неаккуратной остановке он остаётся. Служба сообщает о неожиданном завершении предыдущего запуска и предлагает восстановление. Простое удаление файла блокировки без понимания состояния данных — рискованный ход.
Файл настроек в формате YAML: отступы значимы, табуляции недопустимы. Ошибка в отступе приводит к отказу разбора и немедленному выходу, причём сообщение может указывать не на ту строку, где реально ошибка.
Как устроена
| Файл настроек | /etc/mongod.conf в формате YAML — отступы значимы |
|---|---|
| Каталог данных | /var/lib/mongodb, владелец mongodb |
| Журнал | /var/log/mongodb/mongod.log — основной источник причин |
| Пределы | MongoDB требует повышенных LimitNOFILE и LimitNPROC |
| Порт по умолчанию | 27017 |
Частые ошибки
8 записей базы отмечены за этой службой.
Коды выхода
- status=1/FAILURE в systemdКод 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
Сообщения журнала
- Permission denied в журнале службыОтказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- Address already in use при запуске службыПорт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
Ресурсы и ограничения
- No space left on device в журнале службыНет места на устройстве: разбор по свободным блокам, по inode, по журналу systemd и по удалённым, но открытым файлам.
- Too many open files в журнале службыСлужба исчерпала лимит файловых дескрипторов. Как правильно поднять LimitNOFILE и когда дело в утечке.
Состояния результата
- Failed with result 'oom-kill'Состояние oom-kill: процесс службы убит из-за нехватки памяти. Как понять, упёрлись в предел службы или в память машины.
Ошибки служб
- MongoDB: NotWritablePrimary при записиЗапись отклоняется: узел не является основным в наборе репликации. Разбор выборов и состояния узлов.
- MongoDB: Unable to lock file mongod.lockmongod не запускается: остался файл блокировки после аварийного завершения или каталог принадлежит не тому пользователю.
Коды выхода этой службы
Числа в status=N ниже 200 назначает сама программа, 200 и выше — systemd, когда не смог подготовить запуск.
Диагностика
Главный источник причины: MongoDB пишет подробно.
sudo tail -60 /var/log/mongodb/mongod.logКод завершения и последние строки.
systemctl status mongod --no-pager -lРазбор файла настроек: печатает итоговый вид или ошибку YAML.
sudo -u mongodb mongod --config /etc/mongod.conf --outputConfig 2>&1 | head -20Владелец каталога данных и свободное место.
sudo ls -ld /var/lib/mongodb && df -h /var/lib/mongodbПараметры unit, которые тут важны
- LimitNOFILE=MongoDB требует значения от 64000
- LimitNPROC=ограничение числа процессов тоже повышают
- User=работа от mongodb; каталог данных должен принадлежать ему
- TimeoutStartSec=восстановление больших баз занимает время
Источники
- Документация MongoDB: запуск и устранение неполадок
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)