Rust中的信號處理：Unix信號 vs 信號服務器
如果你正在運行一個服務器，假設服務器需要從磁盤讀取一些文件，比如證書或密鑰。證書經常會發生變化，因此你的服務器必須重新加載它們。如何告訴服務器重新加載這些文件？
傳統的方法是使用Unix信號，你的服務器偵聽特定的信號，如SIGUSR1(用戶定義的信號#1)或SIGHUP(掛起信號)，并且可以在接收到信號時執行你編寫的任何代碼。因此，你的服務器等待適當的信號，接收它，然后重新加載證書。
這種方法工作得很好，但是在實際應用中出現了一些可用性的問題。使用單獨的一個http服務器來處理信號會更好。
下面我們先來看一下使用Unix信號的例子，然后我們使用服務器處理信號來改進這個例子。
首先，我們先創建一個Rust項目：
cargo new signals-servers在Cargo.toml文件中加入以下依賴項：
[dependencies]
axum = "0.7.2"
tokio = { version = "1.25.0", features = ["macros", "rt-multi-thread", "signal"] }在項目根目錄下創建一個cert.pem文件，內容隨便寫，只是為了演示。
Unix信號處理
我們看一個完整的服務器偵聽信號的示例，當你啟動你的服務器時，也啟動一個異步任務(或進程，或線程)來監聽這個信號，當接收到信號時，重新加載證書。
創建一個src/bin/unix_signal.rs文件，代碼如下：
use axum::{routing::get, Router};
use std::process;
use tokio::signal::unix::{signal, SignalKind};
#[tokio::main]
async fn main() {
let _cert = std::fs::read_to_string("cert.pem");
println!("已加載證書，正在啟動web服務器");
println!("PID: {}", process::id());
tokio::select! {
_ = start_normal_server(8080) => {
println!("Web服務器關閉")
}
_ = listen_for_reload(SignalKind::hangup()) => {
println!("信號監聽器停止")
}
}
}
async fn start_normal_server(port: u32) {
// 構建我們的應用程序
let app = Router::new().route("/hello", get(|| async { "Hello, world!" }));
let addr = format!("127.0.0.1:{port}");
let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
axum::serve(listener, app).await.unwrap();
}
async fn listen_for_reload(signal_kind: SignalKind) -> Result<(), std::io::Error> {
// 監聽信號
let mut stream = signal(signal_kind)?;
loop {
stream.recv().await;
match std::fs::read_to_string("cert.pem") {
Ok(_) => eprintln!("重新加載證書成功"),
Err(e) => eprintln!("無法重新加載證書: {e}"),
}
}
}運行如下命令啟動服務器：
cargo run --bin unix_signal
已加載證書，正在啟動web服務器
PID: 41945然后打開一個新的終端，輸入以下命令：
kill -s sighup 41945這是服務器的日志如下：
已加載證書，正在啟動web服務器
PID: 41945
重新加載證書成功這是可行的，但對于發送信號的人來說，這不是一個很好的用戶體驗。假設你是SRE或系統管理員，當需要重新加載服務器證書時，首先查找進程的PID，并使用kill -s sighup pid發送信號。
服務器可能重新加載了，但也許它沒有，可能出現了錯誤，例如新證書無效，或者服務器沒有讀取新證書的權限。系統管理員如何知道是否發生了這種情況？他們應該檢查一下服務器的日志，但這需要切換窗口，或者打開一個不同的程序。
這不是一個很好的用戶體驗。通常，當你運行命令時，希望得到一些反饋。但是當你發送Unix信號時，終端不會給你任何響應。你必須查找服務器的日志并檢查它們，以確保重新加載成功完成。閱讀一個不熟悉的程序日志是很困難的，特別是當日志中有很多其他錯誤時。
Unix信號的主要問題是，它們讓用戶向進程發出信號，但程序不向用戶發送響應。
更好的方法：信號服務器
因此，我們希望進程接受請求(“重新加載您的證書”)，并響應(“是的，它成功了”或“它失敗了，原因如下”)。這聽起來很熟悉——它只是一個普通的請求-響應協議。沒有必要重新發明輪子——我們可以在這個過程中啟動第二個小HTTP服務器。
創建一個src/bin/http_signal.rs文件，代碼如下：
use axum::{
http::StatusCode,
response::IntoResponse,
routing::{get, post},
Router,
};
#[tokio::main]
async fn main() {
let _cert = std::fs::read_to_string("cert.pem");
println!("已加載證書，正在啟動web服務器");
tokio::select! {
_ = start_normal_server(8080) => {
println!("Web服務器關閉")
}
_ = start_control_server(3000) => {
println!("信號服務器關閉")
}
}
}
async fn start_normal_server(port: u32) {
// 構建我們的應用程序
let app = Router::new().route("/hello", get(|| async { "Hello, world!" }));
let addr = format!("127.0.0.1:{port}");
let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
axum::serve(listener, app).await.unwrap();
}
async fn start_control_server(port: u32) {
// 構建信號控制服務器
let app: Router = Router::new().route(
"/reload_certs",
post(|| async {
println!("重新加載證書");
match std::fs::read_to_string("cert.pem") {
Ok(_) => "重新加載證書成功".into_response(),
Err(e) => {
let error = format!("無法重新加載證書: {e}");
eprintln!("{error}");
let resp = (StatusCode::INTERNAL_SERVER_ERROR, error);
resp.into_response()
}
}
}),
);
let addr = format!("127.0.0.1:{port}");
let listener = tokio::net::TcpListener::bind(addr).await.unwrap();
axum::serve(listener, app).await.unwrap();
}對于SRE或系統管理員來說，這是一個更好的用戶體驗。使用如下命令重新加載證書：
$ curl -X POST 0.0.0.0:3000/reload_certs
重新加載證書成功%如果沒有找到證書，會立即得到有關錯誤的反饋：
$ curl -X POST 0.0.0.0:3000/reload_certs
無法重新加載證書: No such file or directory (os error 2)總結
如果你的程序不需要HTTP或網絡，那么引入一個完整的HTTP框架來監聽信號可能有點多余。因此，根據程序的大小，以及系統管理員的需求或SRE團隊的大小，來決定是否添加HTTP服務器，因為這對于管理流程的人員和軟件來說，它有更好的用戶體驗。
