Skip to content
Librux Runtime Kernel for Robotics development
Librux Runtime Kernel for Robotics development

    Deployment Checks

    Use this page after installing Librux on a host and before treating that host as a managed deployment target.

    These checks answer operational questions.

    • is the installed runtime reachable?
    • is the selected time-sync path accepted for the workload?
    • are the Web/API security gates configured for the deployment network?
    • can managed packages launch through the runtime path?
    • are resource leases visible and released correctly?
    • is cross-host Event delivery ready before collecting one-way latency numbers?

    For benchmark methodology and comparison envelopes, use Benchmarks. This page stays focused on deployment readiness, not performance reporting.

    1. Runtime Install

    Load the installed environment.

    . /opt/librux/env.sh

    Check the service state.

    sudo systemctl status librux-control.service --no-pager
sudo systemctl status librux-resourced.service --no-pager
sudo systemctl status librux-timesyncd.service --no-pager

    Check the local readiness endpoint.

    curl -sf http://127.0.0.1:8001/api/v1/ready

    2. Public SDK Smoke

    Use the installed Python SDK runtime.

    . /opt/librux/env.sh
cd /opt/librux

    Run one declaration smoke and one short local transport smoke.

    python3 tools/qa/fixtures/declare/message/python/primitive_codec_demo.py
python3 benchmarks/transport/event/run_benchmark.py \
  --publisher-language python \
  --subscriber-language python \
  --count 20 \
  --warmup 5 \
  --fail-on-warning

    Healthy smoke runs should report ok and no warning promoted by --fail-on-warning.

    3. Time Sync Acceptance

    Run doctor before accepting cross-host one-way timing.

    librux timesync doctor --wait --stable-polls 3

    Minimum acceptance checks.

    • time_sync_status.enabled = true
    • selected role and leader match the intended topology
    • selected backend is accepted for the workload
    • clock_status.accepted_for_one_way = true
    • clock_status.domain_compatible = true
    • hardware PTP paths have a valid active NIC and no recent ptp4l faults

    Strict 50 us cross-host one-way acceptance requires physical hosts on the same L2 segment, PHC-capable active NICs, an accepted hardware PTP or hardware-backed Librux logical clock path, and accepted application-clock evidence. VM-led or software-timestamp-only runs can validate orchestration and delivery, but their one-way latency rows remain diagnostic.

    Use Time Sync Operations for configuration, startup, recovery, and failure cases.

    4. Web And API Access

    Before exposing the runtime API outside a trusted local environment, confirm.

    • security gates are enabled when remote access is expected
    • allowed CIDRs match the operator network
    • browser login is enabled for Web Console users
    • normal API clients use issued API keys rather than the bootstrap token

    Use Web and API Security for the detailed configuration path.

    5. Managed Package Launch

    Install or select a package that declares at least one resource claim, then launch it through librux launch, librux deploy, or a managed Runtime launch in the Web Console.

    Confirm.

    • package validation succeeds
    • the subsystem package starts through the managed launch path
    • the Resource page shows the lease owner, resource type, and assigned value
    • stopping the package releases the lease

    Use Resource Control for resource semantics and service setup.

    6. Cross-Host Event Gate

    Cross-host one-way Event measurement requires two gates.

    • the Event data path for the exact publisher/subscriber pair is ready
    • the clock path is accepted for one-way timestamp comparison

    Start the publisher with --start-gate-file, then run tools/qa/fixtures/transport/event/python/wait_event_path.py against the publisher-side and subscriber-side control status URLs. For one-way latency acceptance, pass --require-time-sync --stable-polls 3.

    Accepted gate reports should show.

    • requested topics under sender forward_ready_topics
    • requested topics under receiver inbound_ready_topics
    • topology fallback flags set to false
    • data_plane_ready=true
    • time_sync_required=true, time_sync_status=accepted, and time_sync_ready=true
    • latency_evidence_accepted=true
    • final JSON ready == true

    Readiness-only Event smoke proves delivery-path setup only. Do not use its one-way latency rows as accepted performance data.

    7. Shared-Memory Cleanup

    For aarch64, containers, and small-memory hosts, record /dev/shm size and the control backend startup shared-memory summary.

    After control backend shutdown, verify that the default pool and Librux named semaphore files are gone.

    test ! -e /dev/shm/librux_topic_pool
find /dev/shm -maxdepth 1 -name 'sem.librux_*' -print -quit | grep -q . && exit 1 || true

    If a custom topic_buffer_pool_name is used, apply the same check to that /dev/shm/<pool-name> path.

    Result Rule

    Treat a deployment as accepted only when the relevant checks pass for the intended environment. Record VM, software timestamp, stress, or readiness-only runs as diagnostic evidence rather than production timing evidence.