linux中用kill函数给init进程发送一个终止信号会产生什么后果？
init进程是特殊进程，它不接收也不处理信号。你发送终止信号给它是不会有任何结果的。 下面是2.4.0内核源代码中do_signal()函数前面的一段注释：/* * Note that 'init' is a special process: it doesn't get signals it doesn't * want to handle. Thus you cannot kill init even with a SIGKILL even by * mistake. */
Linux ps命令详解？
ps是一个 Linux 命令，显示有关系统上当前正在运行的进程的信息。
一些常见的选项ps是：
-aux：以面向用户的进程状态格式显示所有用户的所有进程的信息。
-ef或-e：以比默认格式提供更多信息的格式显示有关所有进程的信息。
-u USER：仅显示有关以指定用户身份运行的进程的信息。
请注意，ps命令的选项和输出可能因类 Unix 操作系统而异。查阅手册页 ( man ps) 以获取更多信息和用法示例始终是个好主意。
如何解决Linux下信号产生的死锁？
一次测试环境发生了server死锁，整个server的任务线程都被hang住。而死锁的代码就在我负责的程序日志部分中localtime_r函数调用处。
程序日记需要记录打印日志的时间，而localtime_r函数就是用于将系统时间转换为本地时间。同样功能的函数还有localtime。两个函数的区别是：localtime_r是thread-safe，其返回的结果存在由用户提供的buffer中；而localtime返回的结果是指向static变量，多线程环境可被其他线程修改。localtime_r实现中有一把锁，负责lock tzfile中的状态变量，而server就在这里发生死锁。
经过分析死锁是由于发kill信号，信号处理函数引起的。原线程打印程序日志获得localtime_r中需要的锁后，kill信号触发中断处理，正好分配给该线程处理中断。信号处理函数中再次打印日志，调用localtime_r的锁时发生死锁。
之前的信号处理方式为异步方式，同时信号处理函数中做了很多事情。之前大家一直关注线程安全，却从来没有注意过异步信号处理函数的安全性。这次最新版本由于还在开发中，大家调用了大量日志打印，增加了死锁的概率才将这个问题暴露出来。
##Signal Handling and Nonreentrant Functions
信号处理函数不推荐做太多工作，如果调用函数需要是reentrant。reentrant可重新进入的，可以理解为一次调用发生后，不会对该函数的再次调用发生任何影响。即reentrant函数中不可以有static或global变量，不可以分配释放内存，通常不可以使用修改用户提供的对象，修改errno等等。具体可以看
##解决信号处理带来的死锁 异步变同步
自己的第一直觉是既然信号处理函数不可以做太多工作，需要调用non-reentrant函数，那就把日志打印全部去掉好了。但发现，团队项目的信号处理函数中做了大量工作，许多调试方法和调试信息通过kill信号获得，而且这些调用基本都是non-reentrant。所以只能修改信号处理的方案。
信号处理的方式除了异步使用方式还有同步使用方式。同步信号处理
还没有评论，来说两句吧...