85a22271c1
Render -X jobs' windows on the user's own X server with zero client install, mirroring the ssh -X experience: the job command starts with DISPLAY pointed at a per-job TCP listener on the worker, and the user's xcecli relays that listener's byte stream to their local X server. - xcecli: new -X/--x11 flag (interactive=2 + exdata "x11":1). After submit it fetches the per-job MIT-MAGIC-COOKIE-1, registers it in the user's Xauthority, then bridges one xattach websocket to the local X server address parsed from $DISPLAY (unix socket or TCP). The cookie entry is removed when the session ends. Pre-flight checks report missing DISPLAY/xauth before submit. - apiserver: GET /xce/v1/jobs/:id/xattach relays websocket binary frames to the worker's forwarding port (raw TCP, no ttyd). Close codes match the ttyd attach (4000 unreachable, 4001 ended). The job-finished event ends the relay. Teardown closes both hops as soon as either pump exits, so a client disconnect propagates instead of deadlocking in a blocking read. - worker: XJOB jobs with exdata x11=1 skip VNC, listen on 6100-6199, generate a per-job xauth file (/tmp/job_<id>_xauth, worker-side since the worker has no session), export DISPLAY/XAUTHORITY to the command, and bridge the app connection (loopback) with the relay connection (non-loopback; roles classified by source address, not arrival order). A 60 s no-client watchdog reaps jobs nothing ever attached to; the v1 single-connection boundary refuses a second X connection loudly. t1-verified per the plan matrix: window rendering (xclock/xeyes on Xvfb), normal end -> DONE + xauth removed, no-client 60 s reap (137), kill -> immediate teardown with no residue, -I/-I --browse regression, daemon health, missing-DISPLAY error, second-connection refusal. (--xjob VNC on t1 fails for lack of a vncserver binary; pre-existing.) Co-Authored-By: Claude Code <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| include | ||
| scripts | ||
| src | ||
| testsuite | ||
| CLAUDE.md | ||
| meson.build | ||
| README.md | ||
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
-
Cross-Platform Support
- Works on both Windows and Linux
- Abstracts platform-specific implementations
-
Thread Pool
- Configurable number of worker threads
- Efficient request handling
-
System Monitoring
- CPU usage monitoring
- Memory usage monitoring
- Disk space monitoring
-
Process Management
- Spawns child processes for received commands
- Tracks process status
- Manages process lifecycle
-
Network Communication
- TCP socket-based communication
- Simple text-based protocol
-
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!