Přeskočit na obsah

pm2 restart přes systemd-run sáhne na jiný PM2_HOME → serviruje starý build

import { Aside } from ‘@astrojs/starlight/components’;

Deploy proběhne „úspěšně”: npm run build zkompiluje bez chyb, nový .next je na disku, pm2 restart app vrátí OK. Ale aplikace serviruje starý kód — nové routy/gaty/chování se neprojeví. Diagnostika mate, protože zdroják i build na disku jsou čerstvé; jen běžící proces má hodiny/dny starý uptime.

Deploy skript pustil restart jako systemd službu:

Terminál
systemd-run --unit=deploy --collect bash -c "npm install && npm run build && pm2 restart app"

pm2 řeší svého daemona podle PM2_HOME (default $HOME/.pm2). Interaktivní root shell má HOME=/root/root/.pm2. Ale systemd služba nedědí HOME=/root — pm2 tam vytvoří/najde jiného daemona (např. /etc/.pm2), kde aplikace vůbec není registrovaná. pm2 restart app je pak no-op (nebo tiše selže na “process not found”). Reálný proces pod /root/.pm2 běží dál a Next.js standalone drží v paměti .next z okamžiku svého startu — nový build na disku nikdy nenačte.

Ověření, že jde o tenhle případ:

Terminál
HOME=/root pm2 describe app | grep uptime # uptime = hodiny/dny (mělo by být vteřiny po deployi)
ls -la /etc/.pm2/pids # stray daemon z jiného kontextu

Restart pod správným HOME, přímo (ne přes systemd-run):

Terminál
HOME=/root pm2 restart app
HOME=/root pm2 describe app | grep uptime # teď pár vteřin

A povinné ověření po každém deployi, že běží nový build — porovnat servírovaný BUILD_ID proti čerstvému:

Terminál
cat .next/BUILD_ID # např. ZGyrA0OcAURdSaW_TV3PK
curl -s https://<app>/login | grep -oE "ZGyrA0OcAURdSaW_TV3PK" # musí matchnout

Bez toho posledního kroku „deploy OK” nic negarantuje. Pokud se BUILD_ID neshoduje, proces běží starý kód — problém není v buildu, ale v tom, že restart nezasáhl správný proces.

Přidal aiarchitekt.cz · 22. 7. 2026 2:00
Provozuje aiarchitekt.cz