dvorakmortonxd/dvorakmortonxd.dev
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

run the dev server as a system-wide systemd unit (boots without login/linger)

Browse source
This commit is contained in:
Martin Dvořák 2026-09-29 15:46:31 +00:00
commit bfa0840b0e
4 changed files with 119 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

29
agents.md
View file

@ -249,15 +249,18 @@ list reordering, not free placement. Don't confuse the two.
`localhost:3000` keeps the full dev experience; the LAN/tunnel get a plain,
live-reloading site. Use `npm run dev:next` only if you explicitly want the
raw, unprotected server (never point the tunnel at it).
- The dev server normally runs on this host as a **user** systemd unit
(`~/.config/systemd/user/dvorakmortonxd-dev.service`, kept in-repo at
`deploy/dvorakmortonxd-dev.service`). `Linger=yes` for uid 1000 means it starts
at boot without a login. `systemctl --user restart dvorakmortonxd-dev` reloads
it; logs with `journalctl --user -u dvorakmortonxd-dev -f`. From a bare shell
with no session bus, prefix those with
`XDG_RUNTIME_DIR=/run/user/1000 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus`.
The unit pins `HOSTNAME=0.0.0.0` (the script reads that env var) so the tunnel
can reach :3000, and clears a stale `.next/dev/lock` on start.
- The dev server runs on this host as a **system** systemd unit
(`/etc/systemd/system/dvorakmortonxd-dev.service`, kept in-repo at
`deploy/dvorakmortonxd-dev.system.service`, installed by
`deploy/install-system-service.sh`). It is enabled at `multi-user.target`, so
it starts at boot with no login/linger. `systemctl restart dvorakmortonxd-dev`
reloads it; logs with `journalctl -u dvorakmortonxd-dev -f`. The unit pins
`HOSTNAME=0.0.0.0` (the script reads that env var) so the tunnel can reach
:3000, clears a stale `.next/dev/lock` on start, and sets `HOME` because system
units don't inherit a login environment. A per-user twin
(`deploy/dvorakmortonxd-dev.service`) exists for rootless installs; it needs
`loginctl enable-linger` and is driven via `systemctl --user`. Only one of the
two may run at a time — they contend for :3000 and `.next/dev/lock`.
- `allowedDevOrigins` (`next.config.ts`) still matters: the tunnel host and any
LAN origin must be listed or Next rejects the HMR WebSocket with a 403 (the
client then never hydrates — SSR only, icons stacked at `(0,0)`, dead
@ -309,10 +312,10 @@ list reordering, not free placement. Don't confuse the two.
- There is **no test suite**. Verification is `tsc --noEmit`, `eslint`, and
`next build`.
- A dev server may already be running on port 3000 — on this host it is normally
the `dvorakmortonxd-dev` user systemd service, so check
`systemctl --user status dvorakmortonxd-dev` first. Two dev servers on this
repo collide on `.next/dev/lock`; stop the service (or the old process)
before starting the custom server by hand.
the **system** `dvorakmortonxd-dev` service, so check
`systemctl status dvorakmortonxd-dev` first. Two dev servers on this repo
collide on `.next/dev/lock`; stop the service (or the old process) before
starting the custom server by hand.
- Dev-server guard check: `curl -s -o /dev/null -w '%{http_code}' \
http://localhost:3000/__nextjs_server_status` must be `200` (localhost keeps
debug), while the same path through the LAN IP or `beta.dvorakmortonxd.dev`