写在前面
觉得本页面排版单调的话，可以尝试到这里看。
问题背景
在 openwrt 上碰到了一个偶现的 reboot 失效问题。执行 reboot 之后系统并没有重启，此时控制台还能工作。
初步排查
首先复现问题，发现复现后控制台仍可正常运行，但此时重复执行 reboot 也无效，执行 reboot -f 则可正常触发重启。
此处 reboot 是一个指向 busybox 的软链接，从 help 信息
-f Force (don't go through init)
中可以看出 reboot 和 reboot -f 的区别在于 reboot 会先通知 init 进程进行一系列操作，而 reboot -f 则直接调内核。
看下 busybox 源码， 如果带了 -f 则直接调用 C 库的 reboot 函数，如果没有带 -f 参数，则只会通过 kill 发信号给 1号进程。
if (!(flags & 4)) { /* no -f */
//TODO: I tend to think that signalling linuxrc is wrong
// pity original author didn't comment on it...
if (ENABLE_LINUXRC) {
/* talk to linuxrc */
/* bbox init/linuxrc assumed */
pid_t *pidlist = find_pid_by_name("linuxrc");
if (pidlist[0] > 0)
rc = kill(pidlist[0], signals[which]);
if (ENABLE_FEATURE_CLEAN_UP)
free(pidlist);
}
if (rc) {
/* talk to init */
if (!ENABLE_FEATURE_CALL_TELINIT) {
/* bbox init assumed */
rc = kill(1, signals[which]);
if (init_was_not_there())
rc = kill(1, signals[which]);
} else {
/* SysV style init assumed */
/* runlevels:
* 0 == shutdown
* 6 == reboot */
execlp(CONFIG_TELINIT_PATH,
CONFIG_TELINIT_PATH,
which == 2 ? "6" : "0",
(char *)NULL
);
bb_perror_msg_and_die("can't execute '%s'",
CONFIG_TELINIT_PATH);
}
}
} else {
rc = reboot(magic[which]);
}
目前 reboot -f 正常，那问题就出在用户空间调用 reboot() 之前的操作中了。
现场分析
既然知道了 reboot 是通过发送信号给 init 进程，那么下一步自然就是搞清楚 init 进程为什么卡住了。
出问题时控制台还能用，这是个好消息。先通过 ps 列出进程信息看下，发现 procd 处于 S 状态。
但只知道这个没太大作用，我们需要更多信息，幸好 linux 还有 proc 文件系统
知道了某个进程的 pid 号。就可以在 /proc/<pid> 目录下，获取到大量的进程相关信息。例如 cat /proc/1/status 查看状态信息 , cat /proc/1/stack 查看栈信息。
$ cat /proc/1/stack
[<ffffff800808526c>] __switch_to+0x90/0xc4
[<ffffff80080f78c4>] futex_wait_queue_me+0xb8/0x108
[<ffffff80080f8018>] futex_wait+0xcc/0x1b4
[<ffffff80080f9728>] do_futex+0xdc/0x940
[<ffffff80080fa0c8>] SyS_futex+0x13c/0x148
[<ffffff800808325c>] __sys_trace+0x4c/0x4c
[<ffffffffffffffff>] 0xffffffffffffffff
从栈信息看，似乎在等待某个锁。
跟踪工具
情况又清晰了一点，但还不够，下一步用跟踪工具看下。
先上 strace， strace 是跟踪进程行为的利器, 可以直接用 strace 来启动一个程序，从头开始跟踪，例如 strace reboot ，也可以在程序运行过程中，通过指定 pid 动态 attach 上去，中途开始跟踪，例如目前这种情况，在 reboot 之前先运行 strace -p 1，即可观察卡住前 1号进程 都执行了什么操作。
从 strace 的输出，加上我自己增加的一些 log 验证，此时已经锁定到问题出在一个打印语句中，展开后是对 vsyslog 的调用。init 就卡在这个调用中，一去不复返。
如果有 gdb 那就更简单了，直接在卡住后连上去，看下 backtrace，不仅能直接看到 init 调用了 vsyslog ，还能进一步看到是 glibc 内部在 vsyslog 中又调用了 realloc，最终卡住。log 如下（本机的一些路径信息用 *** 代替了）
(gdb) bt
#0 0x0000007f8f5948e0 in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x0000007f8f543420 in realloc () from /lib/libc.so.6
#2 0x0000007f8f539108 in _IO_mem_finish () from /lib/libc.so.6
#3 0x0000007f8f5316c8 in fclose@@GLIBC_2.17 () from /lib/libc.so.6
#4 0x0000007f8f586d94 in __vsyslog_chk () from /lib/libc.so.6
#5 0x0000007f8f6a727c in vsyslog (__ap=..., __fmt=0x40c98c "- shutdown -\n",
__pri=6)
at /***-glibc/toolchain/include/bits/syslog.h:47
#6 ulog_syslog (ap=..., fmt=0x40c98c "- shutdown -\n", priority=6)
at /***/compile_dir/target/libubox-2016-02-26/ulog.c:117
#7 ulog (priority=priority@entry=6, fmt=fmt@entry=0x40c98c "- shutdown -\n")
at /***/compile_dir/target/libubox-2016-02-26/ulog.c:172
#8 0x0000000000404c84 in state_enter ()
at /***/compile_dir/target/procd-2016-02-08/state.c:155
#9 0x0000000000404314 in signal_shutdown (signal=<optimized out>,
siginfo=<optimized out>, data=<optimized out>)
at /***/compile_dir/target/procd-2016-02-08/signal.c:61
#10 <signal handler called>
---Type <return> to continue, or q <return> to quit---
#11 0x0000007f8f565070 in fork () from /lib/libc.so.6
#12 0x000000000040b19c in queue_next ()
at /***/compile_dir/target/procd-2016-02-08/plug/hotplug.c:335
#13 0x0000007f8f6a3ce0 in uloop_handle_processes ()
at /***/compile_dir/target/libubox-2016-02-26/uloop.c:545
#14 uloop_run ()
at /***/compile_dir/target/libubox-2016-02-26/uloop.c:685
#15 0x0000000000404074 in main (argc=1, argv=0x7fdf7255c8)
at /***/compile_dir/target/procd-2016-02-08/procd.c:75
分析原因
找到了卡住的点，搜索一番，问题的原因也就很明显了。这是一个异步信号安全问题。
前面说到 reboot 时是发送了一个信号给 1号进程， 而 1号进程procd 的这段出问题代码，正是在信号处理函数中被调用的。
搜下 信号处理 死锁 之类的关键词，就可以搜到很多人前仆后继地踩了这个坑。信号的到来会打断正常的执行流程，转而执行异步信号处理函数，由于不确定被打断的位置，所以异步信号处理函数的编写是很有讲究的，只能调用异步信号安全的函数。可以在 man 7 signal 中找到这个异步信号安全函数的列表。太占篇幅这里就不列了。
除了这些函数，其他的调用都不保证是安全的。本例中是调用了syslog, 里面执行了内存分配操作。此时如果信号发生时正常流程中也在执行内存分配操作，那就可能发生死锁，因为 glibc 中的内存分配操作是有锁的，正常流程中上锁之后被信号打断，信号处理函数中又去拿这个锁，就死锁了。
此处要区分好 线程安全 和 异步信号安全。例如
lock
do something
unlock
有锁保护之后，多线程调用这段代码，任意时刻只有一个线程可拿到锁，就保证只会有一个线程在执行中间的 do something，但当某个线程拿到锁后正在执行 do something时，是可以被信号打断的。如果信号处理函数中，也尝试执行这段函数，那么信号处理函数就会卡在 lock 上一直拿不到锁。
回到问题本身，这个问题的直接原因是信号处理函数中调用了 LOG，而展开后调用了不安全的 vsyslog 。
但解决问题不能只是简单地注释掉这行，这样治标不治本，因为这个信号处理函数中还调用了不少其他函数，都是有风险的。
要解决这个问题，还得完全按标准来，保证信号处理函数中只调用异步信号安全的函数，才能永绝后患。
方案一
为了满足异步信号安全，在信号处理函数中编程就难免限制多多，束手束脚，申请个内存，加个打印，都有可能死锁。
一个常用的方式是将异步信号处理改成同步信号处理。思路就是将信号屏蔽掉，专门开一个线程开处理信号。
可以参考 Linux 多线程应用中如何编写安全的信号处理函数
这里贴下 man pthread_sigmask 中的例子，主线程中先屏蔽一些信号，然后创建了一个特定的线程，通过 sigwait 来检测处理这些信号。如此一来处理信号就是在正常的上下文中完成的，不必考虑线程安全问题。
EXAMPLE
The program below blocks some signals in the main thread, and then creates a dedicated thread to fetch those signals via sigwait(3).
The following shell session demonstrates its use:
$ ./a.out &
[1] 5423
$ kill -QUIT %1
Signal handling thread got signal 3
$ kill -USR1 %1
Signal handling thread got signal 10
$ kill -TERM %1
[1]+ Terminated ./a.out
Program source
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <errno.h>
/* Simple error handling functions */
#define handle_error_en(en, msg) \
do { errno = en; perror(msg); exit(EXIT_FAILURE); } while (0)
/* 信号处理线程 */
static void *
sig_thread(void *arg)
{
sigset_t *set = arg;
int s, sig;
for (;;) {
s = sigwait(set, &sig); /* 主动等待指定的信号集 */
if (s != 0)
handle_error_en(s, "sigwait");
printf("Signal handling thread got signal %d\n", sig); /* 进行信号处理，此时不必局限于调用异步信号安全的函数 */
}
}
int
main(int argc, char *argv[])
{
pthread_t thread;
sigset_t set;
int s;
/* Block SIGQUIT and SIGUSR1; other threads created by main()
will inherit a copy of the signal mask. */
sigemptyset(&set); /* 创建一个空信号集 */
sigaddset(&set, SIGQUIT); /* 将SIGQUIT加入信号集 */
sigaddset(&set, SIGUSR1); /* 将SIGUSR1加入信号集 */
s = pthread_sigmask(SIG_BLOCK, &set, NULL); /* 屏蔽信号集，屏蔽后内核收到这些信号，不会触发任何异步的信号处理函数，只是登记下来 */
if (s != 0)
handle_error_en(s, "pthread_sigmask");
s = pthread_create(&thread, NULL, &sig_thread, (void *) &set); /* 创建信号处理线程，传入屏蔽的信号集，也就是要同步处理的信号集 */
if (s != 0)
handle_error_en(s, "pthread_create");
/* Main thread carries on to create other threads and/or do
other work */
pause(); /* Dummy pause so we can test program */
}
了解了这种同步信号处理模型，那目前的问题能否套用呢 ？ 很遗憾不行，因为这种方式需要屏蔽信号，而信号的屏蔽是会被 fork 继承的，回到问题本身，这次的主角是 1号进程procd，整个用户空间的其他进程全是它的子进程，牵一发而动全身，信号屏蔽还是暂不考虑了。
方案二
既然不能屏蔽信号，那异步信号处理函数就还是存在。可以考虑把原来的信号处理函数做到事情挪出来，放到独立的一个线程中去做，异步信号处理函数只负责通知下这个线程干活。
怎么通知呢? man 7 signal 看看有什么异步信号安全的函数可以用，看起来 sim_post 似乎不错。
首先初始化一个 semaphore， 然后在信号处理线程中调用 sem_wait, 等到后执行实际的信号处理 , 而在异步信号处理函数中仅调用 sem_post，起到通知的作用。
这个方案的问题在于引入了多线程。本来 procd 是单线程的，其中用到的 uloop 等也并未考虑多线程下的线程安全，因此这里是有风险的，搞不好解 bug 就变成写 bug 了。
方案三
方案二的思路是没问题的，异步信号处理函数中只做最简单的事情，安全可靠，实际上的复杂操作留给正常的线程处理。
如果要避免多线程，那就得想办法在主线程中加入对信号的等待和处理，然后只在信号处理函数中进行简单操作，触发主线程处理。
具体的实现就多种多样了，例如最简单的，信号处理函数中将信号记录到全局变量中，主线程轮询。但轮询消耗资源呀，所以更好的做法是主线程阻塞在某个操作上，在信号到来打断这个阻塞操作后进行处理。
对于 procd，其循环是使用的 uloop，而 uloop 中会使用 epoll 监控指定的 fd，并调用回调函数。
看看信号安全函数列表，read 和 write 都是异步信号安全的函数，由此我们可以开一个 pipe 或者 socket，一端由异步信号处理函数写入，另一端由工作在正常进程上下文中的回调函数读出并处理。
最终我们使用了方案三，具体的是使用了管道，并直接复用了 openwrt 的 ustream ，这里展开就得涉及到 procd init 的工作流程分析了，后续有机会再写吧。
有一点可以提下，方案一和二用在 procd 中还有一个问题，就是不能跟原有的 uloop 中的 epoll 顺畅配合，会导致 reboot 要做的事情堆积在队列中却触发不了处理，需要等其他事件来打断这个 epoll, 而方案三则没有这个问题。这也是 procd 和 uloop 的实现导致的，暂不展开。
其他
信号的细节还是蛮多的，例如同一信号多次发生会怎样，多个阻塞信号的到达顺序，进程级别的屏蔽处理和线程级别的屏蔽处理的差异，fork 和 exec 时的行为等。
异步信号同步化的方式，也有很多文章阐述，例如 signalfd 等本文都没提及。
说回 procd，为什么原生的实现可以这么任性，直接在信号处理函数中调用非异步信号安全的函数呢? 这可能是 openwrt 默认 C库 是用的 musl 的原因吧。