Investigate enabling systemd user services in sandbox containers #19

Problem

When running OpenClaw (or other daemon-oriented tools) inside a Navigator sandbox, the onboarding wizard detects that systemd user services are unavailable and skips service installation:

┌ Systemd
│ Systemd user services are unavailable. Skipping lingering checks and service install.
│
┌ Gateway service
│ Systemd user services are unavailable; skipping service install.
│ Use your container supervisor or `docker compose up -d`.

This means tools that rely on systemctl --user to install and start background services (like the OpenClaw gateway daemon) cannot do so automatically. Users must manually start the gateway after onboarding.

Current workaround

We added an openclaw-start helper script (deploy/docker/openclaw-start.sh) that runs onboarding then starts the gateway in the foreground. This works but is OpenClaw-specific and doesn't solve the general problem for other tools that expect systemd.

Proposed investigation

Determine whether we can enable systemd (specifically systemd --user) inside sandbox containers:

1. Feasibility: Can systemd --user run without being PID 1? The sandbox entrypoint is navigator-sandbox (Rust binary) which must remain PID 1 for process management, SSH server, and proxy. Systemd user instances run as a regular user process (systemd --user), so this may be possible without replacing PID 1.

2. Requirements: What capabilities, mounts, and packages would be needed? Likely /run/user/<uid>, dbus-user-session, and the systemd package itself. Evaluate the image size impact.

3. Alternatives: If full systemd is too heavy, consider:

   • A lightweight service manager (e.g., s6-overlay, supervisord) that tools could hook into
   • A shim that translates systemctl --user enable/start calls into something the sandbox supervisor understands
   • Documenting a standard pattern for background services in sandboxes

Context

• Sandbox Dockerfile: deploy/docker/Dockerfile.sandbox
• Sandbox entrypoint: crates/navigator-sandbox/src/lib.rs (runs as PID 1, manages SSH server + proxy + child process)
• The sandbox already has zombie reaping via a SIGCHLD handler in the entrypoint
• Base image: python:3.12-slim (Debian)

Originally by @drew on 2026-02-18T23:29:15.250-08:00