PostgreSQL Startup Failed: `could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock"`

This incident looks simple but often reveals orchestration gaps in production Linux environments.

Incident symptom

sudo systemctl start postgresql

Service fails, and instance log shows:

FATAL: could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": No such file or directory

Root cause

/var/run (or /run) is volatile (tmpfs) and gets wiped on reboot.
PostgreSQL expects runtime socket directory to exist before bind.
Service orchestration did not recreate the directory before startup.

Field troubleshooting workflow

sudo -u postgres /usr/bin/postgres -D /var/lib/pgsql/data
ss -ltnp | grep 5432
ls -ld /var/run/postgresql /run/postgresql 2>/dev/null

Hotfix

sudo mkdir -p /var/run/postgresql
sudo chown postgres:postgres /var/run/postgresql
sudo chmod 775 /var/run/postgresql
sudo systemctl start postgresql

Definitive fix (systemd override)

[Service]
RuntimeDirectory=postgresql
RuntimeDirectoryMode=0775

Apply:

sudo systemctl daemon-reload
sudo systemctl restart postgresql

Optional tmpfiles.d fallback:

d /var/run/postgresql 0775 postgres postgres -

Security note

Use controlled permissions (775/770 as applicable). Avoid 777 on runtime socket paths.

Conclusion

This is not about creating a folder manually. It is about making service runtime idempotent and reboot-safe. Once runtime directory lifecycle is declared properly in systemd, startup becomes predictable and resilient.

This post is licensed under CC BY-NC.