← Назад к списку
Железо и софт • 06.06.2026

Prometheus не запускается ошибка failed to lock tsdb directory как исправить блокировку

Развернул систему мониторинга Prometheus на сервере Linux для сбора метрик инфраструктуры. После аварийной перезагрузки хоста из-за сбоя по питанию сервис наотрез отказывается запускаться. В логах конфигурации (`prometheus.log`) бесконечно сыплется критическая ошибка ядра: «Opening storage failed: lock tsdb directory: open /var/lib/prometheus/data/lock: permission denied» или «file already locked». При этом свободного места на диске много, а права на папки не менялись. Из-за чего сервер мониторинга уходит в этот аварийный ступор блокировки базы данных и как правильно снять блокировочный маркер без потери накопленной метрики?

Ответы (5)

Артем Метрика
Здорово! Ошибка "lock tsdb directory failed" — это классический защитный механизм временных рядов базы данных TSDB. При нормальном старте Прометеус создает в каталоге данных невидимый пустой файл `lock`. Это нужно, чтобы два запущенных параллельно экземпляра программы случайно не начали одновременно писать логи в одну и ту же папку, разрушая структуру секторов. При корректном выключении этот файл стирается. Но если сервер упал аварийно, маркер блокировки зависает на диске, а при новом старте движок спотыкается о собственный старый замок и блокирует запуск.
Марина Девопс
Если фоновая служба не может подняться из-за мертвого файла-замка, его необходимо принудительно ликвидировать в терминале строго по шагам:
1. Подключитесь к вашему серверу по SSH от имени суперпользователя root.
2. Принудительно остановите зависший системный юнит, чтобы освободить дескрипторы: `sudo systemctl stop prometheus`.
3. Перейдите в рабочий каталог базы данных TSDB командой: `cd /var/lib/prometheus/data/`.
4. Найдите мешающий маркерный файл блокировки и удалите его из файловой системы: `sudo rm -f lock`.
5. Запустите сервис заново командой `sudo systemctl start prometheus` и проверьте статус через `systemctl status prometheus` — мост сбора метрик успешно оживет.
Дмитрий Сис
Ребята, если лог ошибки содержит фразу "Permission denied", то корень проблемы кроется в сломанных правах Unix. Часто после ручных манипуляций или бэкапов папок от имени root владелец каталогов слетает. Системный демон, работающий под ограниченным пользователем `prometheus`, пытается обновить хэш-индексы внутри папки `/var/lib/prometheus/`, но операционная система блокирует запись. Восстановить сетевые и файловые сокеты можно за секунду, выдав правильного владельца рекурсивно командой `sudo chown -R prometheus:prometheus /var/lib/prometheus/`.
Никита Мониторинг
Если удаление файла выдает ошибку "resource busy", это значит, что скрытый старый экземпляр приложения реально застрял в процессах ОЗУ и удерживает порт. Ликвидируйте его по инструкции:
1. Вызовите сетевой сканер портов для порта по умолчанию: `sudo netstat -tulpn | grep :9090` (или используйте `ss -lntp`).
2. Найдите в выведенной строке идентификатор процесса PID (например, 7812).
3. Если netstat пуст, найдите процесс по дескриптору открытого файла: `sudo lsof /var/lib/prometheus/data/lock`.
4. Жестко завершите дерево процессов командой силы: `sudo kill -9 7812` (замените цифры на ваш PID).
5. Теперь спокойно запускайте системную службу через systemctl, база данных разблокируется.
Роман Клауд
Тщательно проверяйте тип файловой системы, куда вы монтируете хранилище TSDB. Если ваша папка данных лежит на удаленном сетевом диске NFS или примонтирована через сетевой мост AWS EFS, стандартные системные вызовы fcntl-блокировок файлов в Linux могут работать некорректно или зависать при обрывах сетевых пакетов. В таком случае в параметры запуска Прометеуса в файле сервиса рекомендуется дописать флаг `--storage.tsdb.no-lockfile`, который принудительно отключит создание замков на диске.

Ваш ответ