certbot: shutdown cancels an in-flight ACME order and skips DNS-01 TXT cleanup
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
阅读 dstack/certbot/cli/src/main.rs 和 dstack/certbot/src/acme_client.rs,重点查看 shutdown select、renew_inner 流程以及第 185 行附近的 DNS-01 清理。跟踪现有的 renew_timeout 行为,并运行 certbot 测试或与 shutdown 相关的检查。完成的标准是:shutdown 能在有界期限内处理空闲和正在进行的续期,同时不遗留 TXT 记录或授权状态。
由索引模型根据 Issue 内容生成。
描述
Follow-up to #924.
The shutdown path added in #924 cancels the daemon future rather than letting it unwind:
// dstack/certbot/cli/src/main.rs
tokio::select! {
_ = bot.run() => unreachable!("certbot daemon returned"),
result = shutdown_signal() => result?,
}
If the signal lands while renew_inner is mid-ACME-order, bot.run() is dropped at its current await point and the cleanup at the end of the DNS-01 flow never runs:
// dstack/certbot/src/acme_client.rs:185
if let Err(err) = self.dns01_client.remove_record(&challenge.id).await {
error!("failed to remove dns record {}: {err}", challenge.id);
}
Result: a stale _acme-challenge TXT record left in the DNS zone, plus a pending authorization at the CA.
This is not a regression — before #924 the default SIGTERM disposition killed the process at the same point with the same effect — and it is self-healing, because set_txt_records calls remove_txt_records(&acme_domain) before publishing new ones on the next attempt. But "stop the daemon cleanly" currently means "stop promptly", not "stop without leaving state behind", and the gap is worth closing.
Proposal
Give the loop a cancellation token instead of dropping the future:
- check the token at the top of each iteration and in the interval wait (
select!betweensleep(renew_interval)and cancellation) — this covers the idle case, which is the overwhelmingly common one and is already instant today; - for the in-flight case, either let the current renewal run to completion under a bounded grace period before exiting, or make the DNS-01 challenge cleanup drop-safe (scope guard) so cancellation at any await point still removes the TXT record.
The grace period must stay bounded — renew_timeout already caps a single renewal, so reusing it as the shutdown deadline is a reasonable ceiling.
- 主要语言
- Rust
- 星标
- 555
- 派生
- 97
- 平均合并
- 1 天 3 小时
- 30 天内合并 PR
- 199
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
Dstack-TEE/dstack 的其他 Issue
-
难度 5/5 一周以上 新手友好度 35/100
Dstack-TEE/dstack#1384 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 30/100
Dstack-TEE/dstack#1301 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 55/100
Dstack-TEE/dstack#1300 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1299 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
Dstack-TEE/dstack#1298 ·
维护者通常 1 天内回复
查看 Dstack-TEE/dstack 的全部 Issue
相似的 Issue
-
area/cli parity
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
A-Picking A-UI C-Bug D-Trivial S-Ready-For-Implementation
难度 2/5 1-3 小时 新手友好度 72/100
bevyengine/bevy#26029 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 75/100
-
ai_p3 comp-protocols
难度 2/5 1-3 小时 新手友好度 74/100
ClickHouse/ClickHouse#123884 ·
维护者通常 1 天内回复
-
state:needs triage
难度 2/5 1-3 小时 新手友好度 64/100
zed-industries/zed#65146 ·
维护者通常 1 天内回复