No. systemd is a full system init plus a service manager plus a journal
plus a dozen other things. Gula is a single-purpose process supervisor
that you typically run under systemd, not in place of it. A common
deployment is a single systemd unit that launches gula run --config /etc/gula/gula.yaml, and that unit owns the application stack.
Not yet. Memory limits are enforced from user space by polling RSS via
sysinfo and reacting via the configured memory_threshold_action. This
is sufficient for "kill the misbehaving Python service" but it is not the
same as a cgroup memory.max hard limit.
A cgroup v2 backend is a possible future addition, but it is not part of the 0.1.x behavior.
Gula does work correctly when it is launched inside an externally managed CPU
boundary, such as a systemd service or slice with AllowedCPUs=3-6. In that
mode, gula validate checks process affinity values against the inherited
Cpus_allowed_list, and workers can be pinned to individual CPUs inside that
range. Gula does not yet create or manage those cgroups itself.
Gula relies on /proc, pidfd_open(2), ioprio_set(2), and POSIX process
groups with negative-PID kill(2) semantics. macOS lacks /proc and
pidfd; Windows lacks all of the above. Porting would mean rewriting most
of src/utils/ and src/process/execution/ against per-OS abstractions,
which is out of scope for the 0.1.x line.
ROS 2 launch describes how to start a graph of nodes. It does not
monitor them, restart them, or enforce resource limits. Gula complements
launch: use launch to build the command lines (with parameter files,
remapping, etc.), then put those commands in a gula.yaml so Gula owns
the lifecycle. The optional iceoryx2 heartbeat feature is specifically
designed to detect when a ROS-style middleware node has wedged.
YAML is the only supported config format in 0.1.x. It works well for nested,
human-edited files with comments, and it maps directly onto the serde
configuration structs used by gula validate.
Other formats would need explicit parser support, schema updates, tests, and docs before they could be treated as supported.
Not in the 0.1.x line.
Gula is intentionally CLI-first right now. The supported user-facing
interface is the gula binary plus YAML configuration. The 0.1.x package does
not expose a Rust library target.
If you need programmatic integration today, prefer one of these approaches:
- Generate YAML and call
gula validate/gula runas a subprocess. - Vendor against the current source and accept that internals may change.
There is no embedder hook you need to wire up for scheduling. Commands are run
as sh -c <command>, and when affinity, niceness, or ionice are set,
Gula applies those settings inside its own child spawn path immediately before
exec.
Gula has an extensive Rust test suite split between in-source unit tests,
integration tests under tests/,
and benchmark regression tests under benchmarks/tests/. The integration and
example-config tests spawn the actual gula binary against fixtures in
config/,
templates/,
and examples/.
The name comes from Gula, the Sumerian goddess associated with healing and restoration.