高可用性计算：如何处理不返回的系统调用，而不冒误报的风险？

我有一个进程在 Linux 计算机上运行，​​作为高可用性系统的一部分。该进程有一个主线程，用于接收来自网络上其他计算机的请求并响应它们。还有一个心跳线程定期发送多播心跳数据包，让网络上的其他进程知道该进程仍然存在并且可用 - 如果它们在一段时间内没有收到任何心跳数据包，则其中之一他们将假设该进程已经死亡并将接管其职责，以便整个系统可以继续工作。

这一切都运行得很好，但有一天整个系统失败了，当我调查原因时，我发现了以下内容：

1. 由于（显然）盒子的 Linux 内核中存在错误，该进程的主线程进行的系统调用引发了内核“oops”。
2. 由于内核“oops”，系统调用永远不会返回，导致进程的主线程永久挂起。
3. 心跳线程 OTOH 继续正确运行，这意味着网络上的其他节点从未意识到该节点发生故障，并且没有一个节点介入来接管其职责......因此所请求的任务没有执行并且系统的运行实际上停止了。

我的问题是，是否有一个优雅的解决方案可以处理此类故障？ （显然要做的一件事是修复 Linux 内核，这样它就不会“哎呀”，但考虑到 Linux 内核的复杂性，如果我的软件也能更优雅地处理未来的其他内核错误，那就太好了）。

我不喜欢的一种解决方案是将心跳生成器放入主线程中，而不是将其作为单独的线程运行，或者以其他方式将其绑定到主线程，这样如果主线程无限期地挂起，心跳不会被发送。我不喜欢这个解决方案的原因是因为主线程不是实时线程，因此这样做会引入偶尔误报的可能性，其中缓慢完成的操作被误认为是节点故障。如果可以的话，我希望避免误报。

理想情况下，有某种方法可以确保失败的系统调用返回错误代码，或者如果不可能，则使我的进程崩溃；其中任何一个都会停止心跳数据包的生成并允许故障转移继续进行。有什么方法可以做到这一点，或者不可靠的内核是否也会导致我的用户进程不可靠？

我的第二个建议是使用 ptrace 来查找当前指令指针。您可以有一个父线程来跟踪您的进程并每秒中断它以检查当前的 RIP 值。这有点复杂，所以我编写了一个演示程序：（仅限 x86_64，但这应该可以通过更改寄存器名称来修复。）

#define _GNU_SOURCE
#include <unistd.h>
#include <sched.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/syscall.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <linux/ptrace.h>
#include <sys/user.h>
#include <time.h>

// this number is arbitrary - find a better one.
#define STACK_SIZE (1024 * 1024)

int main_thread(void *ptr) {
    // "main" thread is now running under the monitor
    printf("Hello from main!");
    while (1) {
        int c = getchar();
        if (c == EOF) { break; }
        nanosleep(&(struct timespec) {0, 200 * 1000 * 1000}, NULL);
        putchar(c);
    }
    return 0;
}

int main(int argc, char *argv[]) {
    void *vstack = malloc(STACK_SIZE);
    pid_t v;
    if (clone(main_thread, vstack + STACK_SIZE, CLONE_PARENT_SETTID | CLONE_FILES | CLONE_FS | CLONE_IO, NULL, &v) == -1) { // you'll want to check these flags
        perror("failed to spawn child task");
        return 3;
    }
    printf("Target: %d; %d\n", v, getpid());
    long ptv = ptrace(PTRACE_SEIZE, v, NULL, NULL);
    if (ptv == -1) {
        perror("failed monitor sieze");
        exit(1);
    }
    struct user_regs_struct regs;
    fprintf(stderr, "beginning monitor...\n");
    while (1) {
        sleep(1);
        long ptv = ptrace(PTRACE_INTERRUPT, v, NULL, NULL);
        if (ptv == -1) {
            perror("failed to interrupt main thread");
            break;
        }
        int status;
        if (waitpid(v, &status, __WCLONE) == -1) {
            perror("target wait failed");
            break;
        }
        if (!WIFSTOPPED(status)) { // this section is messy. do it better.
            fputs("target wait went wrong", stderr);
            break;
        }
        if ((status >> 8) != (SIGTRAP | PTRACE_EVENT_STOP << 8)) {
            fputs("target wait went wrong (2)", stderr);
            break;
        }
        ptv = ptrace(PTRACE_GETREGS, v, NULL, &regs);
        if (ptv == -1) {
            perror("failed to peek at registers of thread");
            break;
        }
        fprintf(stderr, "%d -> RIP %x RSP %x\n", time(NULL), regs.rip, regs.rsp);
        ptv = ptrace(PTRACE_CONT, v, NULL, NULL);
        if (ptv == -1) {
            perror("failed to resume main thread");
            break;
        }
    }
    return 2;
}

请注意，这不是生产质量的代码。你需要做很多修复工作。

基于此，您应该能够确定程序计数器是否正在前进，并且可以将其与其他信息（例如/proc/PID/status) 来查找系统调用是否忙。您还可以扩展 ptrace 的使用来检查正在使用哪些系统调用，以便您可以检查等待的系统调用是否合理。

这是一个 hacky 解决方案，但我认为您不会找到解决此问题的非 hacky 解决方案。尽管存在黑客行为，但我不认为（这是未经测试的）它会特别慢；我的实现每秒暂停一次受监控的线程，持续很短的时间 - 我猜这将在 100 微秒的范围内。理论上，效率损失约为 0.01%。