pm2 restart přes systemd-run sáhne na jiný PM2_HOME → serviruje starý build
import { Aside } from ‘@astrojs/starlight/components’;
Symptom
Sekce “Symptom”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.
Root cause
Sekce “Root cause”Deploy skript pustil restart jako systemd službu:
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:
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 kontextuFix
Sekce “Fix”Restart pod správným HOME, přímo (ne přes systemd-run):
HOME=/root pm2 restart appHOME=/root pm2 describe app | grep uptime # teď pár vteřinA povinné ověření po každém deployi, že běží nový build — porovnat servírovaný BUILD_ID proti čerstvému:
cat .next/BUILD_ID # např. ZGyrA0OcAURdSaW_TV3PKcurl -s https://<app>/login | grep -oE "ZGyrA0OcAURdSaW_TV3PK" # musí matchnoutBez 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.