Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

F0001 1С:Предприятие и СУБД

PostgreSQL Error F0001 lock_file_exists: Удаление postmaster.pid

Обновлено: 26.08.2026 · Официальная документация ↗
  • Служба PostgreSQL не запускается: FATAL: F0001: lock file "postmaster.pid" already exists.
  • В логах фиксируется сообщение: Is another postmaster already running in data directory "..."?.
  • Сбой автоматического рестарта PostgreSQL после внезапного отключения питания сервера (Power Outage).
  • 1С:Предприятие сообщает о недоступности сервера баз данных.

1. Проверка: Действительно ли запущен другой процесс PostgreSQL?

Перед удалением lock-файла критически важно убедиться, что в операционной системе не работает реальный процесс PostgreSQL с этой директорией данных, иначе удаление приведет к повреждению базы данных!

# 1. Просмотр содержимого postmaster.pid (первая строка — это PID процесса):
cat /var/lib/postgresql/data/postmaster.pid

# 2. Проверка, жив ли процесс с этим PID:
PID=$(head -n 1 /var/lib/postgresql/data/postmaster.pid)
ps -p $PID -o comm,args

2. Сценарий А: Процесс действительно запущен (зависший процесс)

Если процесс существует и висит, завершите его штатно или принудительно:

# Завершение зависшего инстанса
kill -SIGTERM $PID

# Если не помогло в течение 30 секунд:
kill -SIGQUIT $PID

3. Сценарий Б: Процесс отсутствует (фантомный lock-файл после падения ОС)

Если команда ps -p $PID не вернула запущенного процесса postgres, значит сервер упал аварийно и не успел удалить файл блокировки. Удалите его вручную:

# 1. Удаление lock-файла в PGDATA:
rm -f /var/lib/postgresql/data/postmaster.pid

# 2. Удаление lock-файла сокета в /tmp (или /var/run/postgresql):
rm -f /tmp/.s.PGSQL.5432.lock
rm -f /var/run/postgresql/.s.PGSQL.5432.lock

# 3. Штатный запуск службы через systemd:
systemctl start postgresql

4. Проверка статуса запуска и целостности

systemctl status postgresql
journalctl -u postgresql -n 50 --no-pager
💡 Практика специалистов: Никогда не добавляйте авто-удаление postmaster.pid в скрипты запуска (ExecStartPre в systemd) — при сбоях кластеризации (Split-Brain в Patroni/Pacemaker) это гарантированно приведет к уничтожению данных двумя мастерами.

Частые вопросы (FAQ)

Какую информацию хранит файл postmaster.pid?

В нем записаны: 1) PID главного процесса, 2) путь к каталогу данных (PGDATA), 3) время запуска, 4) номер порта, 5) путь к сокету, 6) статус разделяемой памяти (shared memory info).

Что произойдет, если удалить postmaster.pid при работающем сервере?

Сам работающий сервер не упадет немедленно, но потеряет защиту: второй процесс postgres (или скрипт бэкапа) сможет инициализироваться на тех же файлах, что приведет к мгновенному разрушению страниц базы (Data Corruption).

Почему systemd не удаляет postmaster.pid автоматически?

Это защитный механизм ядра PostgreSQL. Ядро намеренно требует вмешательства администратора для гарантии того, что два процесса не получат одновременный доступ на запись в один PGDATA.

Что делать, если сокет-файл заблокирован другим приложением?

Убедитесь, что порт 5432 не занят другой версией PostgreSQL или контейнером Docker через команду: ss -tulpn | grep 5432.

Полезные материалы
Рекомендуем