Prometheus: каталог данных занят другим экземпляром — причины и решение

Вероятные причины

По порядку: сверху то, что встречается чаще.

Блокировка осталась от прерванного запуска

Аварийное завершение оставляет файл блокировки. Новый запуск считает, что данные заняты.
Два экземпляра на одном каталоге

Так бывает при ручном запуске поверх службы или при двух unit-файлах на одни данные.
Каталог данных принадлежит не пользователю службы

После восстановления из копии владелец мог измениться, и служба не может создать блокировку.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Сообщение о блокировке.

sudo tail -30 /var/log/syslog 2>/dev/null | grep -i prometheus || journalctl -u prometheus -n 30 --no-pager

Работающие процессы.

pgrep -a prometheus

Владелец каталога данных.

sudo ls -ld /var/lib/prometheus

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Блокировка осталась от прерванного запуска

Почему происходит: Аварийное завершение оставляет файл блокировки. Новый запуск считает, что данные заняты.

Как проверить

Убедитесь, что процессов нет, и посмотрите файл.

pgrep -a prometheus
sudo ls -l /var/lib/prometheus/lock 2>/dev/null

Как исправить

При отсутствии процессов удалите файл блокировки и запустите службу. При работающем процессе — сначала остановите службу.

sudo systemctl stop prometheus && sudo rm -f /var/lib/prometheus/lock && sudo systemctl start prometheus

2. Два экземпляра на одном каталоге

Почему происходит: Так бывает при ручном запуске поверх службы или при двух unit-файлах на одни данные.

Как проверить

Посмотрите процессы и их ключи.

pgrep -a prometheus
systemctl list-units "prometheus*" --all --no-pager

Как исправить: Оставьте один экземпляр на каталог данных. Для второго нужен свой каталог и свой порт.

3. Каталог данных принадлежит не пользователю службы

Почему происходит: После восстановления из копии владелец мог измениться, и служба не может создать блокировку.

Как проверить

Посмотрите владельца.

sudo ls -ld /var/lib/prometheus
systemctl show prometheus -p User

Как исправить: Смените владельца каталога данных на пользователя службы и запустите её заново.

Пример вывода

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

prometheus[4200]: level=error msg="opening storage failed" err="lock DB directory: resource temporarily unavailable"
systemd[1]: prometheus.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

MongoDB: Unable to lock file mongod.lock mongod не запускается: остался файл блокировки после аварийного завершения или каталог принадлежит не тому пользователю.
Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
status=1/FAILURE в systemd Код 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
Grafana: расширение не загружается из-за подписи Расширение не появляется в интерфейсе: не подписано или подпись не совпадает. Как разрешить осознанно.
MySQL: InnoDB не запускается после аварийного завершения Ошибки InnoDB при старте: повреждение страниц, несовпадение журнала, режим принудительного восстановления.
RabbitMQ: узел не находит свои данные после смены имени машины Имя узла RabbitMQ включает имя хоста. После его смены брокер не видит прежние очереди.
Redis: MISCONF Errors writing to the RDB snapshot Redis отказывается принимать запись: не удалось сохранить снимок на диск. Место, права, настройка overcommit.
postgresql.service активен, а кластер не работает Обёртка postgresql.service — пустой oneshot. Почему её состояние ничего не говорит о кластере и что смотреть.

Где встречается чаще всего

prometheus.service 5

Источники

Документация Prometheus: хранилище документация программы
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено принудительным завершением процесса с оставшейся блокировкой. собственная проверка, systemd 255
сверено 15 сентября 2026