No description
Find a file
Rongsong Shen 7b274ec0df
fix(deploy-ha): stop-all.sh/cleanup.sh must find the real worker regardless of sudo process-tree depth (bug-1823)
bug-1820's own fix assumed sudo always forks exactly one direct child
that IS the real target, and looked for it via `pgrep -P $PID` (direct
children only). On a real host, sudo commonly interposes an additional
"monitor" process between the invoked sudo and the actual target
(sudo -> monitor -> target, three processes, not two -- standard
sudo 1.8.7+ architecture for signal/exit-status relay) -- a shape this
sandbox's own simpler sudo build doesn't reproduce, which is why
bug-1820 verified clean here but still left the real worker orphaned
on the reporting user's box. `pgrep -P` found and killed the monitor
(a direct child) while the actual worker (the monitor's own child, not
a direct child of the pidfile'd PID) survived untouched.

Replaces the parent/child tree-walking approach entirely with a
depth-independent identity-based re-scan: both generated scripts now
search system-wide (pgrep -f) for any still-running process whose own
cmdline matches the worker's distinguishing identity (-n $NAME plus
this deploy's -l $TOP/logs -- the same two args start-worker.sh's own
"already running" guard checks) and kill every match directly, however
many hops deep it landed. No longer needs to know or guess sudo's
internal process-tree depth.

Live-verified: regression-checked against this sandbox's own real
(2-level) sudo deploy (still clean), and built + killed a synthetic
3-level process tree modeled on the user's exact live report,
confirming the deepest process is found directly and the intermediate
hop then exits on its own once its child is gone.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RLSNJhNoULvVcUhXEFafQC
2026-09-17 04:20:03 +00:00
.claude fix(xce-deploy-ha): stop a stale deploy's processes surviving a hand-typed cleanup mistake 2026-09-15 14:04:16 +00:00
.kiro docs(controller-status): record feature-level GO for Req 13 delta 2026-09-16 18:15:40 +00:00
.wolf fix(deploy-ha): stop-all.sh/cleanup.sh must find the real worker regardless of sudo process-tree depth (bug-1823) 2026-09-17 04:20:03 +00:00
docs/superpowers/plans update documents 2026-08-10 17:51:51 +08:00
issues fix(scheduler): sim resource over-commit, byte-unit display, sync job-state-at-capture 2026-09-12 14:06:41 +00:00
raft chore: checkpoint all prior work for clean state 2026-06-04 13:04:16 +00:00
reports add weekly report and change log for Sep 06-12, 2026 2026-09-13 09:40:47 +00:00
scripts fix(gitea-sync): unwrap buglog.json's {version,bugs} wrapper before iterating (bug-1677) 2026-08-24 14:23:31 +00:00
src fix(deploy-ha): stop-all.sh/cleanup.sh must find the real worker regardless of sudo process-tree depth (bug-1823) 2026-09-17 04:20:03 +00:00
.clang-format reformat code and job array 2025-11-07 16:14:27 +08:00
.gitignore ignore daemon.log token-ledger 2026-08-28 14:33:03 +08:00
.mcp.json checkpoint: bug-851 root cause + raft TLA+ conformance spec family 2026-06-21 14:02:15 +00:00
.opencode.json checkpoint: bug-851 root cause + raft TLA+ conformance spec family 2026-06-21 14:02:15 +00:00
CHANGES.md add weekly report and change log for Sep 06-12, 2026 2026-09-13 09:40:47 +00:00
CLAUDE.md docs(xce-harness-component): document harness in root CLAUDE.md and build-deployment.md 2026-09-14 07:45:26 +00:00
README.md chore(build): make xce-build.sh self-wrap into nix develop 2026-09-07 15:31:06 +00:00

1. commit 规则

  • 每个人 fork 自己的 branch, 从自己的 branch 做 PR,review 完再 commit

2. code format

2.1. C

推荐使用 clang-format,公共配置放在源码里面 xce/.clang-format

(理论上直接使用源码里面 xce/.clang-format 文件格式不会变)

2.1.1. vscode 可以在配置中加上如下内容

"C_Cpp.clang_format_style": "WebKit",
"C_Cpp.clang_format_fallbackStyle": "WebKit",

2.1.2. vim & emacs

clang-format -style="{BasedOnStyle: webkit}" -i XX.c

2.2. golang

使用默认 gofmt

3. build environment and build (example of ubuntu)

3.1 build environment

  • Install nix package management tool
sh <(curl -L https://nixos.org/nix/install) --daemon
  • Edit /etc/nix/nix.conf to make sure
experimental-features = nix-command flakes
sandbox = true
sandbox-fallback = false
substituters = https://mirrors.ustc.edu.cn/nix-channels/store https://cache.nixos.org https://cache.nixos.org/
trusted-users = root <your account>

make sure that you have restarted nix-daemon service after you have changed /etc/nix/nix.conf

  • Install socat and config ssh (for clone by ssh protocol)
nix profile add nixpkgs#socat

.ssh/config

Host gitea.shenrs.eu
	HostName gitea.shenrs.eu
	IdentityFile ~/.ssh/id_ed25519
	ProxyCommand socat - openssl-connect:gitea.shenrs.eu:2022,snihost=gitea.shenrs.eu,verify=0

3.2 checkout source code

git clone ssh://forgejo@gitea.shenrs.eu/rshen/xce.git
cd xce

(参考第 1 节,fork 自己的 branch 再提交 PR)

3.3 build (for package and release)

cd xce/src

# for build debug version
nix build .#xcecore_debug

# for normal build
nix build .#xcecore

You can find the generated binaries at =result= directory

构建现在是**完全 hermetic(离线)**的,无需再加 --option sandbox false。 所有 Go 依赖都已 vendored(go mod vendor,提交到各模块的 vendor/ 目录), Python 组件 xceadmin 也通过 pip install --no-build-isolation --no-index 从 nix 环境安装,构建阶段不再访问网络。因此在开启 sandbox(sandbox = true) 的机器上也能直接构建,不会再出现向 goproxy.cn / PyPI 请求而 DNS 解析失败的问题。

3.3.1 更新 Go 依赖(vendor 维护)

Go 模块(frontend/apiserver、frontend/xcecli、 autoscaler/providers/baidu/src/bcctool)的依赖以 vendor/ 目录的形式提交进仓库, 构建时 tools/go_build 使用 GOFLAGS=-mod=vendor、GOPROXY=off 完全离线编译。

当修改了某个模块的 go.mod / go.sum(新增、升级、删除依赖)后,需要在 nix develop 环境内重新生成对应模块的 vendor/ 并提交:

cd xce/src
nix develop

# 以 apiserver 为例,其他两个模块同理
cd frontend/apiserver
go mod tidy
go mod vendor
cd -

# vendor/ 必须被 git 跟踪,否则 flake 构建(只读取 git 已跟踪/暂存的文件)看不到它
git add frontend/apiserver/go.mod frontend/apiserver/go.sum frontend/apiserver/vendor

注意:nix build 从 git 树取源码,未被 git add 的 vendor/ 文件不会进入构建, 会导致 -mod=vendor 报 inconsistent vendoring 而失败。改完依赖记得 git add vendor/。

3.4 build (for daily develop)

日常开发推荐直接使用 src/tools/xce-build.sh(若在 Claude Code 中开发,对应的是 /xce-build skill), 它会执行 meson setup / meson compile,并在 asan profile 下跑测试。该脚本会自动进入 nix develop 环境(脚本开头检测 IN_NIX_SHELL,未设置时自动用 nix develop 重新执行自身),无需手动 nix develop 或额外包一层,直接跑即可:

cd xce/src

tools/xce-build.sh              # 全部组件 + 全部测试 (asan profile, 输出到 xce.build/)
tools/xce-build.sh controller   # 只构建/测试 controller (lib + controller + xce_test)
tools/xce-build.sh worker       # 只构建 worker
tools/xce-build.sh scheduler    # 只构建/测试 scheduler
tools/xce-build.sh apiserver    # 只构建/测试 apiserver + xcecli (Go)

(如果已经身处 nix develop 交互式 shell 内运行以上命令,脚本会检测到 IN_NIX_SHELL 已设置,跳过重新 进入的步骤,直接执行构建。)

支持三种 profile(tools/xce-build.sh [component] [profile]):

  • asan(默认):debug + AddressSanitizer,输出目录 xce.build/,会运行测试
  • debug:-O0 -g3 无 sanitizer,输出目录 build.dbg/,仅编译,用于 gdb 调试
  • release:-O3 无 sanitizer,输出目录 build.release/,仅编译,用于 soak/性能测试

注意:单组件构建默认会先 rm -rf 对应的 build 目录再重新配置,若同一目录下已有其他组件的产物会被清掉; 需要在同一目录下累积多个组件时加 --incremental(增量 reconfigure,不清空目录)。

也可以手动执行底层的 nix + meson 命令(xce-build.sh 实际上就是对下面步骤的封装):

cd xce/src
nix develop

# using meson to generated build configuration (debug and address sanitize)

meson setup xce.build --buildtype=debug -Db_sanitize=address

# run meson to build
meson compile -C xce.build

# The generated files will be in xce.build/

3.5 build AppImage package

cd xce/src
nix build .#xce.appImage

This will create an all-in-one xce.AppImage (available at ./result) which contains everything for package delivery.

4. misc

4.1. Windows remap ctrl and alt key

create a reg file, e.g. remapkey.reg

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,05,00,00,00,38,00,1d,00,1d,00,38,00,38,e0,1d,e0,1d,e0,38,e0,00,00,00,00

then double click remapkey.reg to import it. Restart OS.