myxce/src/worker
Rongsong Shen 9369b87152
fix(worker): stop treating systemd's UINT64_MAX sentinel as real rusage data
collect_job_rusages() (xcecd_cgroups.c) reads CPUUsageNSec/MemoryCurrent/
MemorySwapCurrent/TasksCurrent via D-Bus and only checked whether the
round trip itself succeeded (r >= 0). systemd's own convention -- not
previously accounted for here -- is to report UINT64_MAX for a counter
that isn't actually being tracked yet, not an error and not zero.

For MemoryCurrent specifically, an unguarded sentinel read produced
(float)UINT64_MAX / (1024*1024) == 17592186044416.0 (2^44) as a single
job's "memory usage", which the scheduler's rusage reconciliation then
summed across every RUN job that hit the same condition -- a live replay
session showed exactly 19 * 2^44 = 334251534843904.0 ("used=304.00 TB")
for 19 affected jobs, matching to the bit.

Added sd_resource_counter_is_available() and gated all four property
reads on it. Applied uniformly (not just MemoryCurrent) since systemd
uses the identical convention for the other three counters. Left the
existing memory_rss MB wire unit alone (bug-1735's established
contract, also relied on by the controller's own display pipeline) --
changing it would need auditing that separate consumer, out of scope
here.

bug-1814.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
2026-09-15 11:21:55 +00:00
..
include fix(worker): real maxswap/maxtmp detection; feat(scheduler): annotate multi-slot assigned jobs 2026-09-07 04:39:22 +00:00
scripts import worker code 2025-11-24 15:53:31 +08:00
src fix(worker): stop treating systemd's UINT64_MAX sentinel as real rusage data 2026-09-15 11:21:55 +00:00
testsuite fix(worker): stop treating systemd's UINT64_MAX sentinel as real rusage data 2026-09-15 11:21:55 +00:00
CLAUDE.md update documents 2026-08-10 17:51:51 +08:00
meson.build feat(worker-rejoin-resync): task 4.3 - wire query receipt and post-join gate 2026-09-01 18:01:03 +00:00
README.md import worker code 2025-11-24 15:53:31 +08:00

Cross-Platform Xcecd Process

This is a cross-platform process manager implementation in C that supports both Linux and Windows platforms. The xcecd provides the following features:

  • Sending status to the remote controller module at port 6789 and receive job requests
  • Maintains a configurable thread pool for request processing
  • Periodically collects and updates system resource status
  • Manages child processes spawned from received commands
  • Caches job status information
  • Uses Unix Domain Sockets for communication between the main process and worker processes

Building

Prerequisites

  • C compiler with C11 support
  • Windows: Visual Studio
  • Linux: GCC and development tools

Build Instructions

On Linux

make

On Windows

nmake

Configuration

The xcecd can be configured through the following parameters in main.c:

  • thread_pool_size: Number of threads in the thread pool (default: 4)
  • resource_update_interval: Interval for updating system resource status in seconds (default: 1)
  • job_status_update_interval: Interval for updating job status in seconds (default: 1)
  • port: Port number to listen on (default: 7869)
  • acct_file_path: Path to the accounting file (default: /tmp/xcecd.acct)
  • log_file_path: Path to the log file (default: /tmp/xcecd.log)
  • domain_sock_path: Path to the Unix Domain Socket file (default: /tmp/xcecd.sock)
  • remote_host: Remote server address (default: lchen02)
  • remote_port: Remote server port (default: 6789)
  • update_interval: Interval for sending status updates to the remote server (default: 1 second)

Usage

Starting the Xcecd

On Windows:

xcecd.exe

On Linux:

./xcecd

Features

  1. Cross-Platform Support

    • Works on both Windows and Linux
    • Abstracts platform-specific implementations
  2. Thread Pool

    • Configurable number of worker threads
    • Efficient request handling
  3. System Monitoring

    • CPU usage monitoring
    • Memory usage monitoring
    • Disk space monitoring
  4. Process Management

    • Spawns child processes for received commands
    • Tracks process status
    • Manages process lifecycle
  5. Network Communication

    • TCP socket-based communication
    • Simple text-based protocol
  6. Unix Domain Socket Communication

    • Uses Unix Domain Sockets for communication between the main process and worker processes

Architecture

The xcecd is composed of several key components:

  • Main Process: Coordinates all components and manages the lifecycle
  • Thread Pool: Handles concurrent request processing
  • System Monitor: Collects and updates system resource information
  • Process Manager: Manages child processes and their status
  • Network Handler: Handles network communication and request receiving
  • Resource Sync: Synchronizes and aggregates resource collection thread, system monitor, and job information

Contributing

Feel free to submit issues and enhancement requests!