Background service
Keep running when closed - your computer stays reachable from your phone and the web after you quit Foxl
Foxl is described as a 24/7 agent, but until you turn this on the local server and the relay connection both belong to the app window - so closing the window takes the machine offline.
Settings > General > Keep running when closed moves both into a small background service that the operating system owns. The app then attaches to that service when you open it, and quitting changes nothing.
Off by default, and turning it off puts everything back the way it was. The switch only appears on the desktop app, and only on a platform that supports it - an older build or an unsupported system shows no switch at all rather than one that cannot work.
What gets installed
| Platform | Mechanism |
|---|---|
| macOS | A launchd user agent |
| Linux | A systemd user unit |
| Windows | A Task Scheduler task that runs at sign-in |
Nothing needs administrator or root: it is a per-user service, installed and removed by the switch.
On macOS it appears in System Settings > Login Items as Foxl, with the Foxl icon. Machines that had the setting on before that was true are corrected on the next launch - there is nothing to switch off and on again.
The service file is rewritten on every launch of the app, so anything you edit
into it by hand - an environment variable, a path - is undone the next time Foxl
opens. Settings that need to reach the service have their own switches in the app.
The file hardcodes the path to the installed app, so if you move Foxl the service
exits with status 78 rather than looping; opening the installed app once rewrites
the file to the new location. Its own state lives in ~/.foxl/daemon.json,
readable only by your user - it holds the relay refresh token the service signs in with to
reach your phone and the local connection token that guards the server on your
machine.
Turning it on or off restarts Foxl
Both directions restart the app, and the restart is the point rather than a side effect: ownership of the server and of the phone connection moves between two processes, and several things are decided once at launch from which process owns them.
Foxl waits for the handover, says it is restarting, and comes back attached. If the restart stalls it is forced through, because a half-converted app is worse than either state - after turning the setting off, a stay-behind app would serve locally with no relay connection at all, so your phone could not reach the machine until some later launch.
While it is running
- The app no longer starts a second server of its own. The two would fight over the same port.
- The Restart button asks the service to restart rather than killing it.
- A Restart service link sits on the status line under the switch, for the case where the service is running but its server is wedged. It reports the outcome rather than just firing off the request.
- The status line distinguishes "the service is running", "the service is running and signed in" - reaching this computer from your phone needs an account, so a signed-out service says so - and "the service is missing from this system", the one state where Restart service reinstalls rather than restarts.
- If the operating system has lost the service - the file is on disk but its manager no longer knows it - every launch of the app checks for that case and repairs it, and Restart service reinstalls it instead of restarting nothing.
- If the service genuinely cannot be started, Foxl turns the setting off itself, runs the server inside the app so the window still opens, and says so under the switch: "Foxl could not start the background service, so this app is running the server itself. Turn this back on to try again."
It picks up updates on its own
The service is a plain background process, so it has no updater of its own. It watches its own bytes instead: when the build on disk is no longer the one it is running, it stands down and the operating system starts it again on the new build, within about two minutes.
| Platform | What is replaced |
|---|---|
| macOS, Linux | The whole service replaces itself. |
| Windows | The part that serves your phone is replaced immediately; the rest is updated the next time you open the app. |
Before this, a machine whose owner left the app closed - which is the entire point of the setting - kept serving the previous build until the app was next launched.
It comes back if something kills it
Anything that stops the service without turning the setting off used to leave it stopped, so the machine stayed unreachable with the switch still reading as on. The service now tells the system it wants to be restarted in that case:
- macOS, Linux - back within about ten seconds.
- Windows - the task is started by signing in, so it waits for your next sign-in.
A stop you actually asked for - turning the setting off, or an app update replacing the service - still stops cleanly.
Limits worth knowing
The service runs headless, so two things still need the app open:
- Desktop notifications. A question from Foxl Code still reaches you through your phone and the in-app panel as usual.
- App auto-update. The service updates itself as described above; the app bundle is replaced by the app's own updater.
On Linux the installer also asks the system to keep your user services alive after logout. If that prompt is declined, Foxl says so and the service runs until you log out.
Logs
One append-only file per day at:
~/.foxl/logs/daemon-<date>.logFiles older than 14 days are deleted. A 24/7 process needs a retention cap; the app's own per-session logs are not pruned the same way.
Related
- Desktop relay - how the phone and web app reach this computer at all.
- Mobile Apps - what a phone can and cannot do while your desktop is unreachable.
- Troubleshooting