sigterm_handler receive signal (sigterm信号)

当程序运行时，操作系统可以向进程发送信号来通知它发生了某些事件。其中，SIGTERM信号是一种终止信号，通常用于请求进程正常退出。在这种情况下，如果进程注册了SIGTERM信号处理程序（signal handler），该处理程序就会被调用来处理这个信号。

对于"sigterm_handler receive signal"这个内容，我们可以从信号处理程序的注册、信号的接收和处理几个方面展开详细的分析。

1. 信号处理程序的注册

程序要接收和处理SIGTERM信号，需要先注册一个信号处理程序。信号处理程序是一个函数，当接收到指定信号时，操作系统会调用这个函数。在Linux下，可以使用signal()或者更安全的sigaction()函数来注册信号处理程序。在注册时，需要指定要处理的信号类型（SIGTERM），以及要调用的处理函数（即sigterm_handler）。

2. 信号的接收

一旦信号处理程序注册成功，当进程接收到SIGTERM信号时，操作系统会根据注册的处理函数来执行相应的操作。SIGTERM信号通常用于请求进程正常退出，因此当接收到这个信号时，进程应该执行清理操作并退出。这个过程并不会立即终止进程，而是给进程一个机会来做一些清理工作。

3. 信号处理

信号处理程序（sigterm_handler）是专门用来处理SIGTERM信号的函数。在这个函数中，通常会实现一些清理工作，比如释放资源、关闭文件、保存数据等。处理完这些操作后，通常会调用exit()函数或者类似的函数来退出进程。值得注意的是，在信号处理程序中应该尽量避免使用一些不可重入的函数，因为信号处理是异步的，可能会导致一些意想不到的问题。

结论

"sigterm_handler receive signal"表明了一个进程注册了SIGTERM信号处理程序，并接收到了这个信号。这个过程是进程正常退出的一部分，是一种优雅的终止方式。通过信号处理程序，进程有机会做一些必要的清理工作，确保退出前的状态是可控的。在实际编程中，合理地处理信号是一个重要的技能，能够提高程序的稳定性和可靠性。

sigint sigterm 有什么区别

区别在于：sigint 程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出 。 sigterm 程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理. 通常用来要求程序自己正常退出. shell命令kill缺省产生这个信号。 词汇详解 intelligence 智能信号; [计] = SIGnal INTelligence,（载波）信号情报。 [例句]It prints a status message and sends the sleep command a SIGINT signal.它将打印状态信息并将sleep命令发送给SIGINT信号。 SIGTERM终止信号; 警告信号; 信号情报; 正常终止。

JVM对于signal的处理及案例分析

Windows的Signal相对少一些, 如下:

Linux的Signal比较多, 如下:

Linux中的Signal可以由 kill 命令发起, 比如 kill -1 [pid] 是对某一个进程发出SIGHUP信息.

JVM 所使用的信号:

信号的类型为 异常、错误、中断和控制 。

表 1

注：

信号名称后提供的数字是该信号的标准数值。

使用 -Xrs（减少信号使用）选项来防止 JVM 处理大多数的信号。有关更多信息，请参阅Oracle 的 Java™ 应用程序启动程序页面。

JVM 线程上的信号 1（SIGHUP）、2（SIGINT）、4（SIGILL）、7（SIGBUS）、8（SIGFPE）、11（SIGSEGV）和 15（SIGTERM）导致 JVM 关闭；因此，应用程序信号处理程序不应该尝试从这些信号恢复，除非它不再需要 JVM。

以上表格引用原文链接:

至于JVM是如何处理这些Signal的, 请参考以下链接:

除了JVM默认处理Signal的行为, 我们还可以自定义 SignalHandler 来做一些额外的工作, 比如在关闭JVM之前做一些回收或记录的事情.

例子:

关闭钩子使用的方法也很简单， ()(Thread hook) 即可。关闭钩子其实可以看成是一个已经初始化了的但还没启动的线程，当 JVM关闭时会并发地执行注册的所有关闭钩子 。

JVM的关闭方式可以分为三种：

注意:Hook线程在JVM 正常关闭 才会执行，在强制关闭时不会执行。(异常关闭没试过, 有空试一下..)

另外在使用关闭钩子还要注意以下几点：

Spring 在初始化容器的时候就会注册一个hook线程用于清理容器.

[图片上传失败...(image-3b)]

JVM进程已经不在了, 重启后, 几分钟到半小时之间, 会看到获取不到spring bean的错误日志, 同时系统服务异常.

[图片上传失败...(image-cfc2ef-90)]

奇怪的是, 2台集群中的其他一台一直都是稳定运行, 只有这台是一直异常状态.

从以上的日志, 可以看出spring容器已经在销毁中了, 感觉是一个正常的关闭系统的流程.

在监控系统(Marvin)中观察了内存的情况, 没有什么波动, 基本排除了oom的情况.

接下来, 我使用jstack输出了当时的线程栈信息, 保留现场痕迹.

[图片上传失败...(image-508b17-90)]

由上图所示, 从jstack日志中发现了2个关键的点:

自此, 大家可能已经看出来, SIGHUP 正是JVM会处理的Signal之一, 并且在上面的表格中已经清楚的写着 SIGHUP 的操作是 挂起, 让JVM正常退出 , SIGHUP 是 中断 类型的信号, 上面对于 中断 类型的信号是这样描述的: 将从 JVM 进程外部异步发出中断信号以请求关闭。

结论:

找不到根本原因, 那么只能是想办法绕过这个问题.

所幸的是, 在搜索问题的时候, 让我知道了Linux还有一个 nohup 的命令.

nohup命令可以将 程序以忽略挂起信号( SIGHUP)的方式运行起来，被运行的程序的输出信息将不会显示到终端。

于是把JVM的启动脚本改动了一下:

[图片上传失败...(image-7897ca-90)]

再次启动后, 稳定运行, 问题解决.

实际上通过JVM本身 -Xrs 的参数应该也能控制忽略SIGHUP信号的, 但是时间关系, 我没去实验..

这里案例也让我学到了很多JVM的处理细节.

同时也有了一些思考:

排查线上故障的基本步骤无非就是

实际上, 前面3步基本上已经能解决大部分的问题了, 剩下的一些疑难问题才会用到第4步. 但是第4步的操作对于实时性的要求是最高的, 必须第一时间搞定, 晚一点可能你就捕捉不到有效的证据了.

在出现故障的情况下, 有时候难免手忙脚乱, 如果有一个可以自动化收集现场证据的脚本, 在出现这种疑难问题的时候将会是一个极大的助力.

Linux终止前台进程的命令

1、首先，连接相应linux主机，进入到linux命令行状态下，等待输入shell指令。

2、其次，以终止进程号1984的nginx子进程为例，在linux命令行中输入：kill -9 1984。

3、最后，按下回车键执行shell指令，此时会看到进程号1984的nginx子进程被成功终止了。

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！