feat(deploy): support systemd --user process manager for nextjs-ssr - #42
feat(deploy): support systemd --user process manager for nextjs-ssr#42keypair34 wants to merge 1 commit into
Conversation
Add an optional `process_manager` field to the nextjs-ssr deploy config. When set to "systemd", the deploy restarts the app via a git-owned `systemctl --user restart <pm2_app>.service` (no sudo, XDG_RUNTIME_DIR set, aborts if the unit is missing) instead of pm2. Default/"pm2" is unchanged. This replaces the pm2 daemon model that could leave an orphaned next-server holding the port after a restart (the karokowe.com gateway-timeout outage); a systemd --user unit is cgroup-supervised so restart reaps the whole tree, and linger makes it boot-persistent with no `pm2 save`. - model: process_manager: Option<String> on DeployConfig and Project - config: merge deploy_config.process_manager into project - deploy: restart_stanza() helper branches pm2 vs systemd, injected into the deploy script; unit tests for both branches - docs: smbcloud-deploy-nextjs skill "Process manager: systemd --user" Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
setoelkahfi
left a comment
setoelkahfi
left a comment
There was a problem hiding this comment.
The systemd path is directionally sound, but the supervisor selector currently fails open to PM2 and the documented migration prerequisite is not present in the repository. Both should be fixed before merge.
| /// deploy script). `port` is only used by the pm2 fallback path. | ||
| fn restart_stanza(process_manager: Option<&str>, port: u16) -> String { | ||
| let use_systemd = process_manager | ||
| .map(|m| m.eq_ignore_ascii_case("systemd")) |
There was a problem hiding this comment.
[P1] Reject unknown process-manager values instead of falling back to PM2. Any configured value other than an exact case-insensitive systemd silently takes the PM2 branch (the new test even codifies Some("other")). On an app already migrated to systemd, a typo such as system can start a second PM2 process or collide with the systemd-owned port, recreating the outage this change is intended to prevent. Please explicitly accept only absent/pm2 and systemd, and return a configuration error for every other value.
| start at boot: `sudo loginctl enable-linger git`. | ||
| 2. Create the `~/.config/systemd/user/<pm2_app>.service` (+ a mode-600 | ||
| `<pm2_app>.env`) and cut over off PM2. Use the migration generator | ||
| `pm2-to-systemd.sh <app> --apply`, which reads the live `pm2 jlist`, |
There was a problem hiding this comment.
[P2] Ship or replace the referenced migration command. pm2-to-systemd.sh is not tracked anywhere in this PR/repository (the only tracked shell scripts are the installers), so a user following these prerequisites cannot create the required unit, and the runtime error also points to a migration that is unavailable. Please add the generator, link to a versioned accessible location, or document the complete unit/env creation and cutover commands here.
2 participants
Add an optional
process_managerfield to the nextjs-ssr deploy config. When set to "systemd", the deploy restarts the app via a git-ownedsystemctl --user restart <pm2_app>.service(no sudo, XDG_RUNTIME_DIR set, aborts if the unit is missing) instead of pm2. Default/"pm2" is unchanged.This replaces the pm2 daemon model that could leave an orphaned next-server holding the port after a restart (the karokowe.com gateway-timeout outage); a systemd --user unit is cgroup-supervised so restart reaps the whole tree, and linger makes it boot-persistent with no
pm2 save.Related Issue
Fixes #
Description
Type of Change
How Has This Been Tested?
cargo test --all-featuressmb <command>)Checklist
cargo check --workspacepassescargo clippy --workspace --tests -- -D warningspassescargo fmt --all -- --checkpassesunwrap()orexpect()calls in production codemod.rsfiles introducedCargo.tomland inherited with{ workspace = true }Release Notes