myxce/src/worker
Rongsong Shen 367af11af1
fix(worker): graceful job kill and catchable stop, as LSF (bug-1957)
A plain kill sent one SIGTERM and never escalated, and a plain stop sent
one uncatchable SIGSTOP. Following LSF's TERMINATE and SUSPEND actions, a
plain kill now sends SIGINT, then SIGTERM, then SIGKILL, and a plain stop
sends SIGTSTP (the job can catch it, prepare and stop itself), then SIGSTOP
if it has not stopped; each next signal follows after the grace period and
only while the job is alive (or not yet stopped). A resume cancels a
pending stop; the job's exit ends any sequence. An explicit signal is
delivered once; a force kill is SIGKILL at once.

- JobSignal gains grace (capnp @2, xce_signal_t.grace): > 0 asks for the
  sequence, in seconds between signals.
- apiserver: job.terminate_interval (default 10 s, LSF's
  JOB_TERMINATE_INTERVAL); jobCtrlParams sends kill = SIGKILL and stop =
  SIGSTOP with that grace when no signal is given; the handler no longer
  pre-fills a default signal.
- worker: grace travels through the job-control task, the kept-signal table
  (pending_signal_*_ex) and the IPC message; the job process runs the
  sequence (job_signal_seq_*, uv timer) and checks stop state in /proc.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-10 10:00:36 +00:00
..
include fix(worker): graceful job kill and catchable stop, as LSF (bug-1957) 2026-10-10 10:00:36 +00:00
scripts import worker code 2025-11-24 15:53:31 +08:00
src fix(worker): graceful job kill and catchable stop, as LSF (bug-1957) 2026-10-10 10:00:36 +00:00
testsuite fix(worker): graceful job kill and catchable stop, as LSF (bug-1957) 2026-10-10 10:00:36 +00:00
CLAUDE.md update documents 2026-08-10 17:51:51 +08:00
meson.build fix(worker): deliver the job-control signal the user asked for (bug-1954) 2026-10-10 09:07:38 +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!