[alexandre-vl]

Summary

• Under a systemd user manager an app runs in a unit of its own: uwsm starts each app as a service (app-Hyprland-zeron@….service), GNOME and KDE as a scope.
  • The engine the app started stayed in that unit's cgroup even with a session of its own.
  • A service stops as soon as its main process exits, and systemd kills everything left in it.
  • So on Hyprland under uwsm, quitting Zeron took its engine down, and every session it ran. crates/engine/src/managed.rs promises those keep running.
• On Linux, a process started detached from within a user unit is now started through systemd-run --user --scope.
  • It gets a transient scope of its own in the app's slice, so it still ends with the graphical session.
  • It keeps the same process and environment.
  • spawn_detached hands it back only once systemd-run has become it, which happens once the scope exists, so an app that exits straight after doesn't take it down either. This costs about 3 ms.
• Fallbacks:
  • Not in a user unit (a login session's scope, a system service, a container, cgroup v1): unchanged.
  • systemd-run missing: the spawn fails, and the command is started as before.
  • systemd-run unable to create the scope: it exits before running the command, still named systemd-run, which is detected, and the command is started as before.
  • A slow manager: the process is handed back after 2 s.
• Why systemd-run (process spawning, please review closely):
  • It is how a launcher gives a process its own scope (GLib and KDE do the same over D-Bus).
  • It comes with systemd, so there's no new dependency. zbus would put a D-Bus stack into the engine and the CLI.
  • --slice= names the app's own slice rather than --slice-inherit (systemd ≥ 251), so older systemd works. --collect needs systemd ≥ 236.
• Applies to every spawn_detached caller:
  • launch(), used by the zgx app, the GPUI app and the CLI.
  • The managed engine's relaunch_self: its successor gets a new scope in the same slice.
  • crates/update's own spawn_detached is unchanged.
• Windows already leaves the app's job object for the same reason.

Test plan

• cargo test --locked -p zeron-launch: 9 passed.
  • cgroup parsing:
    • A slice is found for a uwsm service, a GNOME scope, and a hybrid hierarchy.
    • None is found for a login session, a system service, the manager itself, a delegated cgroup, a container's root, or cgroup v1 only.
  • The systemd-run command line, environment and directory carried over.
  • The hand-over, with stand-in systemd-run scripts that become the command or give up.
• Live, needs a systemd user manager (cargo test -p zeron-launch -- --ignored outlives): passes on CachyOS (systemd 262, Hyprland under uwsm). With the scope step removed it fails: "the detached process went down with the service".
• Reproduced by hand: a setsid child of a transient user service is killed when the service's main process exits. Started through systemd-run --scope, it survives.
• cargo clippy --locked -p zeron-launch --all-targets, cargo check -p zeron-engine -p zeron-cli.
• Not checked: GNOME or KDE sessions, a distro with systemd < 251 (e.g. Ubuntu 22.04), Flatpak.
• Not compiled for macOS or Windows here (no targets installed). On Unix, the existing setsid hook moved unchanged into new_session. The new code is #[cfg(target_os = "linux")], and the Windows branch is untouched.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[alexandre-vl]

The red checks come from zeron/zgx itself, not this change.

• linux-ui / ui-tests and macos / macos-native: zeron-ui's tests don't compile. 398cdab made TranscriptFrame::reset generic, and crates/ui/src/state.rs:5987 and crates/ui/src/transcript.rs:12347 still call it with &[] (E0283, type annotations needed).
• windows / tests: the same two errors, plus test code in crates/engine that calls libc::getrusage, which the Windows libc doesn't have: crates/engine/src/chat_persistence.rs:1200 (6f4e0e5) and crates/engine/src/source_control.rs:4869 (bcd0946).
• zgx / zgx-linux: plugins::official::tests::zeron_v2_is_in_step_with_the_default has failed since c153906 changed apps/zgx/ui/screens/panel/init.luau but not Zeron v2's copy. zgx: Zeron v2's panel gets the active-tab wash fix, so the v2 staleness test passes #1382 brings v2 in step.
• Other PRs into zeron/zgx fail these jobs with the same errors, e.g. Plugins: a plugin's service gets zeron.db, the same file its windows open #1380 and Plugins: a service measures text as its window's canvas does #1367.
• zgx / zgx-macos: the same zeron_v2_is_in_step_with_the_default, plus four rendering tests (visuals_tests, transcript_paint_tests) and five chat-scrolling UI tests. Metal fails to compile zgx's shader fill pipeline ("Compilation failed") on the macos-26-arm64 runner image, 20261102.0473.1. engine: a saved session is used only by the edge and client that issued it #1390, which touches neither crates/launch nor apps/zgx, fails the same tests on the same image.

As for this change:

• zeron-launch built on Windows and macOS without an error or a warning, which settles the test plan's open item about those two platforms.
• linux-core / core-tests ran its five systemd_scope tests, and all five passed.