fix(nb): give the WoW server units a usable PATH #249

Merged

dominik.polakovics merged 1 commit from fix/nb-wow-server-unit-path into main

2026-08-01 17:01:04 +02:00

dominik.polakovics commented

2026-08-01 16:59:56 +02:00

Owner

#248 asserted that these units would inherit the user manager's PATH. That is
wrong, and I should have checked it rather than reasoned about it.

systemctl --user show wow-server.service -p Environment on the deployed unit:

PATH=…coreutils/bin:…findutils/bin:…gnugrep/bin:…gnused/bin:…systemd/bin

NixOS pins a unit's PATH to that set. systemctl --user show-environment shows
something much larger, but that is the manager's environment, and units get
an explicit Environment=PATH= that overrides it. So:

podman — missing. The entire point of the unit.
rsync — missing. The database copy in and back out.
awk — missing.
bash — missing, so #!/usr/bin/env bash would not have resolved either.
/run/wrappers/bin — missing, so no newuidmap/newgidmap. That is the
setuid pair rootless podman uses to write its uid_map, which is the exact
mapping this whole delegation exists to obtain. Without it the units would
have reproduced the single-mapping failure they were written to avoid.

Why it slipped through

The first real launch never reached the units at all. environment.sessionVariables
only apply to newly created login sessions, and the running sway session predated
the deploy, so WOW_SERVER_VIA_SYSTEMD was unset inside Steam and server-up.sh
took its non-delegating path. It failed against the card's image store instead,
which masked the unit bug behind an unrelated one.

Verified separately that a clean login session does pick both variables up
(env -i … bash -l returns them; a plain bash -l does not, because
/etc/profile guards on __NIXOS_SET_ENVIRONMENT_DONE, which an existing
session already has set — that guard is what made an earlier check of mine
report a false negative).

Testing

scripts/test-configuration nb passes. Still unproven end to end: an actual
delegated launch. The tell in server/logs/session.log is
==> delegating server start to wow-server.service.

#248 asserted that these units would inherit the user manager's PATH. That is wrong, and I should have checked it rather than reasoned about it. `systemctl --user show wow-server.service -p Environment` on the deployed unit: ``` PATH=…coreutils/bin:…findutils/bin:…gnugrep/bin:…gnused/bin:…systemd/bin ``` NixOS pins a unit's PATH to that set. `systemctl --user show-environment` shows something much larger, but that is the *manager's* environment, and units get an explicit `Environment=PATH=` that overrides it. So: - `podman` — missing. The entire point of the unit. - `rsync` — missing. The database copy in and back out. - `awk` — missing. - `bash` — missing, so `#!/usr/bin/env bash` would not have resolved either. - `/run/wrappers/bin` — missing, so no `newuidmap`/`newgidmap`. That is the setuid pair rootless podman uses to write its uid_map, which is the exact mapping this whole delegation exists to obtain. Without it the units would have reproduced the single-mapping failure they were written to avoid. ### Why it slipped through The first real launch never reached the units at all. `environment.sessionVariables` only apply to newly created login sessions, and the running sway session predated the deploy, so `WOW_SERVER_VIA_SYSTEMD` was unset inside Steam and `server-up.sh` took its non-delegating path. It failed against the card's image store instead, which masked the unit bug behind an unrelated one. Verified separately that a clean login session does pick both variables up (`env -i … bash -l` returns them; a plain `bash -l` does not, because `/etc/profile` guards on `__NIXOS_SET_ENVIRONMENT_DONE`, which an existing session already has set — that guard is what made an earlier check of mine report a false negative). ### Testing `scripts/test-configuration nb` passes. Still unproven end to end: an actual delegated launch. The tell in `server/logs/session.log` is `==> delegating server start to wow-server.service`.

dominik.polakovics added 1 commit

2026-08-01 16:59:57 +02:00

fix(nb): give the WoW server units a usable PATH 7c41ad7bd2

The previous commit claimed these units would inherit the user manager's PATH.
They do not. NixOS pins a unit's PATH to coreutils, findutils, gnugrep, gnused
and systemd, so podman, rsync and awk were all missing — and so was bash, which
means the scripts' `#!/usr/bin/env bash` shebangs would not have resolved
either.

/run/wrappers is needed for the setuid newuidmap and newgidmap that rootless
podman uses to write its uid_map; that is exactly the mapping the whole
delegation exists to obtain, so without it the units would reproduce the
single-mapping failure they were written to avoid.

Not caught earlier because the first launch never reached the units: the login
session predated the deploy and so lacked WOW_SERVER_VIA_SYSTEMD, and
server-up.sh ran its non-delegating path instead.

dominik.polakovics merged commit 5ba99ec99e into main

2026-08-01 17:01:04 +02:00

dominik.polakovics deleted branch fix/nb-wow-server-unit-path

2026-08-01 17:01:04 +02:00

dominik.polakovics referenced this pull request from a commit

2026-08-01 17:01:06 +02:00

Merge pull request 'fix(nb): give the WoW server units a usable PATH' (#249) from fix/nb-wow-server-unit-path into main