Module system_service 

Installing isb serve as a systemd system unit that runs as the operator: isb serve install --system.

A user unit lives in the user’s slice (user-UID.slice), with everything else that user runs. On a host where agents run as that same user, the slice’s limits (MemoryHigh, MemoryMax, TasksMax) are theirs, and an agent that fills the slice stalls the daemon with it. A system unit runs in system.slice instead, with its own limits, while keeping the user, home, runtime directory and state the CLI expects, so nothing else changes: the CLI finds the daemon at $XDG_RUNTIME_DIR/isb/serve.sock as before.

The installer runs as that user and uses sudo for what needs root (the unit, the system credential, systemctl, lingering).

Structs

Operator

Who the daemon runs as.

Constants

CREDSTORE

The system credential store LoadCredentialEncrypted= searches by name.

MEMORY_MAX

The unit’s own ceilings. Far above what the daemon uses (hundreds of MB, a few hundred tasks), so only a leak in isb itself reaches them. Raise them with a drop-in (sudo systemctl edit isb).

TASKS_MAX

UNIT_PATH

Where the system unit is written.

Functions

install_system_service

Write the system unit and its credential, retire a user unit, (re)start the service and wait until it is healthy. Run as the daemon’s user, not root. Safe to run again: it updates an existing installation.

installed

Is the daemon installed as a system unit on this host?

render_system_unit

The unit. It runs as the operator with their runtime directory, so the socket, state and config are where the CLI looks; it is ordered after the user manager, which creates that directory (lingering starts it at boot).