开发过程中碰到的信号处理场景--笔记

 1. 后台服务启动脚本使用信号  

         Linux的后台服务大部分是有启动脚本，在我们的平台上，有部分启动脚本放在/etc/init.d/ 目录下，比如有这个样的一个服务 svr，它的启动脚本是/etc/init.d/svr，我们会这样设计，对服务的一些操作，都是通过这个脚本来做的，比如 restart／stop／start／reload，就说reload吧，如果你在后台执行/etc/init.d/svr reload，那么这个脚本会做如下操作：

      通过kill -0 pid 判断进程是否存在，

      1、如果进程不存在，则通过命令拉起服务

      2、如果进程存在，则执行  kill -HUP pid 发HUP信号给服务，让服务重新加载配置，当然服务里面需要注册这个信号的处理函数。

2. Nginx升级的时候使用信号

       有本关于的Nginx书说过，Nginx在升级的时候，新的Nginx会发送信号USR1给老的Nginx，老的Nginx接受到这个信号后，就不再处理新的请求，新的请求就交给新的Nginx来处理，等老的Nginx处理完请求后，就自动退出。个人看到这个机制后，发现真的挺不错的，在设计的时候，如果可以考虑到升级场景，尽可能的使代码向后兼容的，对运维和开发的帮助都挺大的。

3. 在调试服务的时候，记得屏蔽掉相关信号

          以前在用gdb调试单进程服务的时候，经常一attach到服务，进程就退出了，gdb提示，** is terminated by signal usr1 之类的，之所以会退出，是因为你attach到服务的时候，服务可能还没注册新号处理函数，就算注册了，这个时候被你attach了，基本上是没有做什么操作，对于操作系统来说，你这个服务对信号没有响应。对此，默认操作是退出。所以在调试服务的时候，要把这些相关的发信号的地方屏蔽掉。