Description
When OpenFox runs as a systemd service (installed via openfox service install), clicking Update in the UI fails with:
/bin/sh: 1: openfox: not found
The UI then suggests running openfox update manually in a terminal, which only works if that terminal's PATH contains ~/.local/bin (and nvm).
Reproduction
- Install OpenFox with npm, Node managed by nvm.
openfox service install (creates a system user service, ExecStart=~/.local/bin/openfox).
- Start the service and click Update in the UI.
Result: Update Failed with /bin/sh: 1: openfox: not found.
Root cause
The update endpoint runs spawn("openfox update", { shell: true }), inheriting the service's environment. A systemd service gets a minimal PATH that contains neither ~/.local/bin (where the launcher is installed by openfox install) nor the nvm node/npm directories, so openfox cannot be resolved.
There is a second failure behind the first: even if the launcher were found, openfox update runs npm install -g openfox@latest. The npm resolved from the service PATH is the system npm (node v22, global prefix /usr, not writable by the user), so the global install would fail with EACCES.
This is a self-inflicted defect: the app installs a service whose PATH cannot run the app's own update mechanism.
Observed workaround
A systemd drop-in prepending the launcher dir (and/or stable node/npm symlinks into ~/.local/bin) to the service PATH:
[Service]
Environment="PATH=/home/<user>/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/snap/bin"
followed by systemctl daemon-reload && systemctl restart openfox.
Proposed fix
The update mechanism should not depend on PATH:
- Spawn the update with the already-resolved executables, e.g.
spawn(process.execPath, [process.argv[1], "update"]) — this is always the running node + the running CLI, regardless of PATH, and also guarantees npm resolves against the correct global prefix.
- Or: have
openfox service install write an Environment="PATH=..." line into the generated unit that includes the launcher directory and the node/npm directory actually in use.
Environment
- OpenFox 2.0.101 (still present in 2.0.127)
- Linux + systemd, Node installed via nvm
Description
When OpenFox runs as a systemd service (installed via
openfox service install), clicking Update in the UI fails with:The UI then suggests running
openfox updatemanually in a terminal, which only works if that terminal's PATH contains~/.local/bin(and nvm).Reproduction
openfox service install(creates a system user service,ExecStart=~/.local/bin/openfox).Result:
Update Failedwith/bin/sh: 1: openfox: not found.Root cause
The update endpoint runs
spawn("openfox update", { shell: true }), inheriting the service's environment. A systemd service gets a minimal PATH that contains neither~/.local/bin(where the launcher is installed byopenfox install) nor the nvm node/npm directories, soopenfoxcannot be resolved.There is a second failure behind the first: even if the launcher were found,
openfox updaterunsnpm install -g openfox@latest. Thenpmresolved from the service PATH is the system npm (node v22, global prefix/usr, not writable by the user), so the global install would fail withEACCES.This is a self-inflicted defect: the app installs a service whose PATH cannot run the app's own update mechanism.
Observed workaround
A systemd drop-in prepending the launcher dir (and/or stable
node/npmsymlinks into~/.local/bin) to the service PATH:followed by
systemctl daemon-reload && systemctl restart openfox.Proposed fix
The update mechanism should not depend on PATH:
spawn(process.execPath, [process.argv[1], "update"])— this is always the running node + the running CLI, regardless of PATH, and also guaranteesnpmresolves against the correct global prefix.openfox service installwrite anEnvironment="PATH=..."line into the generated unit that includes the launcher directory and the node/npm directory actually in use.Environment