Rust中的信号处理:Unix信号 vs 信号服务器

开发 前端
如果你的程序不需要HTTP或网络,那么引入一个完整的HTTP框架来监听信号可能有点多余。因此,根据程序的大小,以及系统管理员的需求或SRE团队的大小,来决定是否添加HTTP服务器,因为这对于管理流程的人员和软件来说,它有更好的用户体验。

如果你正在运行一个服务器,假设服务器需要从磁盘读取一些文件,比如证书或密钥。证书经常会发生变化,因此你的服务器必须重新加载它们。如何告诉服务器重新加载这些文件?

传统的方法是使用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服务器,因为这对于管理流程的人员和软件来说,它有更好的用户体验。

责任编辑:武晓燕 来源: coding到灯火阑珊
相关推荐

2010-04-21 16:42:48

Unix信号量

2010-04-21 16:25:13

Unix信号量

2010-04-21 16:50:31

Unix信号量

2010-04-21 17:10:25

Unix信号量

2010-04-21 15:37:38

Unix信号量

2010-07-30 14:22:47

RIP协议

2019-02-22 14:40:35

信号压缩领域

2017-03-20 13:26:35

英特尔服务器闪存

2015-07-23 15:00:41

DSP

2024-01-03 10:17:51

Linux通信

2019-01-04 12:46:03

程序员技能沟通

2012-11-07 10:57:46

无线路由器飞鱼星

2010-04-09 15:29:10

无线信号故障

2020-02-04 09:18:28

PythonRedis数据

2011-06-30 17:31:32

Qt 多线程 信号

2017-12-06 13:24:57

服务器计算信号

2010-04-13 18:19:57

无线路由器信号

2015-09-08 14:13:59

WiFi信号连接隐藏WiFi

2010-10-08 15:55:38

无线路由信号

2011-06-09 09:45:35

Linux QT 信号
点赞
收藏

51CTO技术栈公众号