Runner Worker Process

<< Click to Display Table of Contents >>

Raynet One > 2026.4 > User Guide > Workspaces in the sidebar menu > Configuration > Runners 

Runner Worker Process

The runner executes inventory jobs and discovery tasks by spawning dedicated worker processes. Each worker process is a separate child process managed by the runner service. This design isolates job execution from the runner service itself, ensuring that a failing job does not affect the stability of the runner or other running jobs.

 

Worker process lifecycle

When the runner receives a job request from the backend, it starts a worker process to handle that job. The runner service monitors the worker process throughout its lifetime. Once the job completes, the worker process exits and the runner reports the result back to the backend.

 

The runner manages the full lifecycle of each worker process, including:

•Allocating the communication ports required for the worker to connect back to the runner service.

•Starting the worker process with the appropriate configuration and connection parameters.

•Forwarding job messages between the backend and the worker process during execution.

•Collecting and reporting the exit code and job result once the worker process completes.

 

IPC communication

The runner service and each worker process communicate using inter-process communication (IPC) over a dynamically allocated local TCP port. The runner service reserves a port for each worker before starting it and passes the port number to the worker as part of its startup parameters. Communication over this channel remains local to the host running the runner service and is not exposed to the network.

 

Job progress messages, log entries, and result data produced by the worker are forwarded through this IPC channel to the runner service, which then relays them to the backend.

 

Shared worker infrastructure

The worker process management infrastructure is implemented in the Runner Core shared library. Both the runner service and the agent use this shared library to spawn and manage worker processes. This ensures consistent behavior and uniform job execution capabilities regardless of whether jobs are dispatched by the runner service or the agent.

 

 

papercliper

Note:
Because the agent uses the same worker process infrastructure as the runner service, agents deployed in your environment execute inventory jobs in the same way as runner-based deployments. The behavior and configuration options are consistent across both deployment types.

 

Worker process configuration

Worker processes are configured through settings applied when the runner service or agent starts. The following parameters influence worker process behavior:

 

•Maximum concurrent workers: Controls how many worker processes the runner may run simultaneously. Increasing this value allows more jobs to be processed in parallel but requires additional system resources on the runner host.

•Log level: Sets the verbosity of log output generated by worker processes. A higher log level produces more detailed output, which is useful for troubleshooting job execution issues.

•Java path: Specifies the path to the Java runtime used by worker processes that execute Java-based inventory instruments. This setting is required when the runner host does not have Java available in the system path.

•Certificate: The TLS certificate used to secure the IPC communication channel between the runner service and worker processes.

 

For general information about the runner and its configuration, see Runners.