Engineering Dispatches

Auditing PM2 Persistence on Production Droplets

2 min read
  • production-auditing
  • pm2
  • systemd

Auditing PM2 Persistence on Production Droplets

Silent crash loops rarely announce themselves. They show up as enabled-but-dead systemd units, duplicate port listeners, and restart counters that climb while dashboards still look green.

Symptoms we watch for

Signal Likely cause
↺ restart count climbing App crash loop or deploy race
Two PM2 homes active Root + user collision
Port listener owned by stale PID Orphaned god daemon

Zero-trust boot checklist

  1. Disable dead user units (pm2-<user>.service) when root owns production.
  2. Run pm2 startup systemd -u root --hp /root.
  3. pm2 save after the fleet is verified online.
systemctl disable pm2-polycracker.service
pm2 startup systemd -u root --hp /root
pm2 save
systemctl is-enabled pm2-root.service

Collision testing

Cross-reference listeners before every deploy:

ss -tulpn | grep ':3000'
pm2 list

If more than one process claims the application port, stop the stale fleet before restarting nginx upstream blocks.

Studio takeaway

Production auditing is not about deleting services aggressively—it is about making one authoritative boot path and documenting which user owns the runtime.

For architecture engagements, contact the studio at [email protected].

← All dispatches