TalonInit

TalonInit is the init system and service supervisor for Vertex Linux. It is built around the special responsibilities of Linux PID 1: mounting early filesystems, validating service dependencies, starting and supervising processes, reaping adopted children, and keeping shutdown orderly.

Note: TalonInit refuses to run as an ordinary process. Use taloninit --check when validating the binary or service configuration on a development host.

Command surface

TalonInit installs one executable and exposes its administrative commands through multicall symlinks.

Command	Purpose
taloninit	Runs the PID 1 boot and supervision loop.
taloninit --check [DIRECTORY]	Performs a safe binary smoke test or validates a complete service directory.
talon-service	Enables, disables, starts, stops, and invokes service actions.
talon-run	Executes POSIX service scripts and their lifecycle hooks.
reboot	Stops services and restarts the machine.
shutdown	Stops services and powers off the machine.
halt	Tears down the system, then waits for a console choice to reboot or power off.

The symlinked commands dispatch through argv[0], keeping the installed command set in one auditable binary.

Validate before boot

Run a smoke test without entering the PID 1 event loop:

taloninit --check

Pass a service directory to strictly parse every TOML service, validate the dependency graph, and print the deterministic startup order:

taloninit --check /etc/taloninit/services

Unknown fields, invalid names, missing dependencies, duplicate dependencies, self-dependencies, and cycles are rejected before boot.

Boot sequence

TalonInit performs the following high-level sequence as PID 1:

1. Blocks the process and power signals handled by its event loop.
2. Parses /etc/fstab and mounts automatic filesystem entries.
3. Loads and validates services from /etc/taloninit/services.
4. Starts enabled services in dependency order.
5. Starts a fallback console when no TOML service files are installed.
6. Reaps service children and adopted descendants when SIGCHLD arrives.
7. Applies each service’s configured restart policy.

TalonInit synchronously consumes SIGCHLD, SIGINT, SIGTERM, SIGPWR, and SIGUSR1. If the event loop encounters a fatal error, PID 1 remains alive so the kernel is not accidentally panicked and the diagnostic remains visible on the console.

Filesystems and swap

At boot, TalonInit parses /etc/fstab in file order. Standard octal field escapes such as \040 are supported.

When /etc/fstab is absent, it mounts a small built-in set suitable for early test images and initramfs roots:

Filesystem	Target
proc	/proc
sysfs	/sys
devtmpfs	/dev
devpts	/dev/pts
tmpfs	/dev/shm, /run

Already-mounted targets are accepted when the live filesystem type matches. Compatibility symlinks are resolved, so /dev and the Vertex target /system/devices are treated as the same location.

• noauto skips an entry.
• nofail turns a mount or swap activation failure into a warning.
• Swap entries support pri=N, discard, discard=once, and discard=pages.
• Bind, move, remount, propagation, and automatic filesystem probing are currently rejected because they require separate idempotence rules.

POSIX service scripts

Package-provided scripts live in /etc/taloninit/services. Enabled services are symlinks in /etc/taloninit/enabled.

#!/usr/bin/talon-run

description="Example daemon"
command=/usr/bin/exampled
command_args="--daemon"
pidfile=/run/exampled.pid
required_files="/etc/exampled.conf"

depend() {
    need network
    use logger
    after entropy
}

start_pre() {
    "$command" --check-config
}

reload() {
    kill -HUP "$(cat "$pidfile")"
}

The runner sources /etc/taloninit/conf.d/SERVICE when it exists. Service scripts should use configurable shell defaults such as ${variable:=default} instead of overwriting values supplied by the administrator.

Common variables

Variable	Purpose
description	Human-readable service description.
command, command_args	Executable and POSIX argument list.
command_background=yes	Backgrounds a command that does not daemonize itself.
service_type=oneshot	Accepts a successful command without requiring a pidfile.
pidfile	Tracks the service process; defaults under /run/taloninit/services.
required_files	Lists files that must exist before start.
start_timeout, stop_timeout	Bound pidfile, start, and stop waits.
extra_commands	Documents custom service functions.
extra_started_commands	Documents custom functions that require a running service.

Scripts may implement start, stop, pre/post hooks, and custom command functions. Without custom start or stop functions, talon-run uses generic pidfile-based lifecycle handling.

Dependency helpers

• need SERVICE declares a hard dependency on another enabled service.
• use SERVICE adds optional ordering when that service is enabled.
• after SERVICE and before SERVICE constrain ordering without requiring the service.

Service administration

talon-service accepts both sentence-like combined actions and service-first commands:

talon-service enable and start sshd
talon-service sshd reload
talon-service stop and disable sshd

Actions run from left to right and stop on the first failure. Enabling and disabling are idempotent.

Direct-process TOML services

The original TOML format remains available for foreground processes supervised directly by PID 1. Each filename defines the service name.

description = "Run the system message bus"
command = ["/usr/bin/dbus-daemon", "--system", "--nofork"]
requires = ["devices"]
restart = "on-failure"

command must begin with an absolute executable path and is executed directly without a shell. restart accepts never, on-failure, or always.

Service names must begin with a lowercase ASCII letter and may contain only lowercase letters, digits, and hyphens. When no TOML services exist, TalonInit starts a fallback console using agetty, getty, or sh.

Shutdown and power actions

An orderly shutdown stops services in reverse dependency order, deactivates swap, unmounts non-root filesystems, calls sync(2), and remounts / read-only before the final power action.

halt completes the same teardown and then displays this console prompt:

System Halted: press enter to reboot or space to shutdown

Build and test

Meson drives packaging builds and installs the multicall symlinks:

meson setup build
meson compile -C build
meson test -C build
meson install -C build

Release, static, and cross builds use Meson options:

meson setup build-release --buildtype=release
meson setup build-static --buildtype=release -Dstatic=true
meson setup build-cross --buildtype=release \
  -Dcargo_target=x86_64-unknown-linux-musl -Dstatic=true

Direct Cargo development remains available:

cargo check
cargo test
cargo run -- --check
cargo run -- --check examples/services

The static feature is a packaging guard for fully static Linux GNU or musl builds. It requires Rust’s crt-static target feature so accidental dynamic PID 1 release builds fail at compile time.

Current boundaries

TalonInit does not yet provide readiness notification, restart backoff, or failure-rate limiting. Dependencies currently order service process startup rather than waiting for application-level readiness.

See also

• Vertex docs
• VX
• Package browser