Linux 进程信号深度解析:从内核机制到实操应用全指南----《Hello Linux!》(15)

Linux 进程信号深度解析:从内核机制到实操应用全指南----《Hello Linux!》(15)

文章目录

前言

在 Linux 系统中,进程信号是一套高效的 “异步通信机制”—— 它如同给进程发送的 “通知”,能够打断进程的正常执行流程,触发预设的处理动作。小到ctrl+c终止前台进程,大到异常崩溃时的核心转储(core dump)、进程间的紧急通知,信号贯穿了 Linux 进程管理的方方面面。

信号的本质是内核向进程传递事件的 “软件中断”,其生命周期涵盖 “产生→发送→保存→递达→处理” 五大环节,背后依赖block(阻塞)、pending(未决)、handler(处理函数)三张核心表的协同工作。本文将从基础认知出发,层层拆解进程信号的核心逻辑:先讲信号的三种处理方式、前台 / 后台进程与信号的关联,再深入信号捕获的signal系统调用、键盘输入触发信号的底层原理;随后详解信号的五种产生途径(键盘、命令、系统调用、异常、软件条件),并剖析内核中信号的保存机制与阻塞 / 未决状态的核心概念;最后结合core dump调试、信号位图管理等实操技巧,帮读者打通 “理论原理” 与 “实际应用” 的壁垒。

无论你是刚接触 Linux 进程编程的新手,还是想深入理解内核信号机制的开发者,都能通过本文掌握信号的核心知识点 —— 包括不可捕获 / 阻塞的 9 号(SIGKILL)与 19 号(SIGSTOP)信号、原子操作的信号位图、alarm闹钟信号等关键细节,轻松应对进程中断、异常处理、进程间简单通信等实际开发场景。

信号的初步认识

1.进程必须要能识别和处理信号–就算这个信号没有被产生,进程也需要具备处理这个信号的能力

–对信号的处理能力,属于进程的内置功能

2.进程没有收到信号,也能知道这些信号的处理方法是什么

3.当进程真的收到了信号,进程可能不会立马处理这个信号,而是等到合适的时候处理

4.进程具有临时保存哪些信号发生了的能力

–因为信号产生到信号被处理之间会有时间窗口
信号的处理方式有三种:(只能三选一哈)

1.默认动作 2.忽略 3.自定义动作(比如:捕捉这个信号)
在Linux中,一次登陆就会有一个终端,一个终端一般只有一个bash;一个bash的话就只允许一个进程是前台进程,但是可以有多个进程是后台进程


这样的话算两次登录哈把进程搞成后台运行的方法:最后加个& eg:./a.out &

注意:只有前台进程才能获取键盘输入 --前台进程搞成其他了的话,bash就用不了了
ctrl+c只能杀掉前台进程,不能杀后台进程

捕获信号的办法

在这里插入图片描述
1到31的信号称为普通信号(掌握这些就就行了)

后面的称为实时信号

eg:SIGHUP这些是宏,其实就是1

想要知道这些信号是干啥用的:man 7 signal可以查询eg:信号的默认处理动作
在这里插入图片描述
这个系统调用接口可以用来捕捉信号–程序里只需要设置一次,往后都有效(但是进程结束了也就没了哈)

这里面的handler是用来修改特定进程对于信号的处理动作的,也可以设置成eg:SIG_IGN这样的(这是信号处理动作的宏定义)信号处理动作的宏定义:

1.SIG_IGN:忽略该信号

2.SIG_DFL:使用系统默认的信号处理动作

–也就是用来改当前进程的handler

使用方法:

注意:不是所有信号都能被signal捕捉到的,在普通信号里面9和19是不行的

键盘数据输入给内核的原理

键盘上有按键输入时会产生硬件中断(通过中断号和中断单元通知CPU),CPU通过中断向量表找到处理问题的方法,然后OS就会接管并执行对应的处理中断的程序

这个中断向量表是OS维护的哈,里面存的是处理中断的那些方法的地址

执行中断的程序:比如:ctrl+c这种特殊组合键,就被OS处理成了信号
直接访问外设的方式,主要是磁盘,显示器,键盘

CPU保存数据的原理:给寄存器的针脚发送高低电平信号
信号其实就是用软件方式,对进程模拟的硬件中断(但不是真的硬件中断哈)
引申:键盘回显到显示器,如果显示器上还要其他数据显示,是不会打乱输入的:

因为键盘的输入是存在自己的缓冲区里面的,只是把这部分数据拷贝了一份给显示器的缓冲区而已

不同的文件会使用不同的缓冲区

core dump

core dump:核心转储

用法:开启gdb调试器之后,core-file core.pid文件 ,然后就会给出出错行是哪个以及报错的信息
SIGINTSIGQUIT的区别就是SIGQUIT除了终止进程,还会core dump
一个进程异常终止时,如果信号的ActionCore的话,OS会将进程在内存中的运行信息转储到进程的当前目录(和进程同一级哈)里面形成core.pid文件 比如core.30238

core的话,进程状态那个core dump那个位置就是1
在默认情况下,云服务器的core功能是关闭的–害怕挂起之后又运行,这样就会产生很多个core.pid文件,这个文件的大小又很大
一些相关的指令:

ulimit -a:列出当前用户所有的进程资源限制配置(比如:核心转储文件大小的限制)

ulimit -c:显示核心转储文件大小的限制

ulimit -c m:把核心转储文件大小的限制改成m(比如1024)–改成非0的,也就开启了core功能

信号的产生

信号的产生和代码的运行是异步的

也就是说,信号可以在代码执行的任何时刻产生
信号的产生常见的方法有五种:

1.键盘组合键 eg:ctrl+c 产生的就是2号信号

2.kill命令 kill 信号的号数(比如2) 给哪个进程(填pid)

3.系统调用

4.异常

5.软件条件

系统调用

主要有killraiseabort
kill:



sig就是要填几号信号

返回值:成功返回0,失败返回-1
raise:这个的话是对调用者(当前进程)发信号

返回值:成功返回0,失败返回非0值
abort



这个的话是给当前进程发送SIGABRT信号(也就是6号信号)

但是这个跟直接给这个进程发送6号信号有点不一样

调用了abort的话,这个信号被捕获了之后,程序还是会被终止(killraise不行哈)

异常

比如:野指针时会让进程崩溃–因为产生了段错误,发送了11号信号

–这种的如果用signal改了行为的话,就会一直发送11号信号

如果此时进程不崩溃的话,这个进程就一直会被调度运行–但是一调度就会被挂起(因为一直出问题)

–也就是出异常了,操作系统不会直接把这个进程给干掉

这是OS给进程发送的信号

–过程:CPU里面存的是虚拟地址,然后交给MMU(内存管理单元)转换成物理地址;但是比如野指针就会导致地址转换失败,触发硬件异常,然后OS就知道有问题了,就会…
引申:1.OS是硬件的管理者
异常不是只有硬件会产生,软件也是会的

比如:管道的读端关闭了,写端还在继续写,这个时候就会异常

软件条件

比如:闹钟alarm

闹钟不是异常,是系统层面的一种软件条件
alarm:时间到了会发送14号信号



seconds:想多少秒之后触发就写多少

返回值:返回的是上一次的闹钟还有多久触发(已经触发了的话,返回的是0)

闹钟是设置多少次就响多少次–跟signal区分

信号的发送

对于普通信号,进程会记录有没有收到信号,收到的是哪种信号

用的是位图去管理(接收到这个信号,就那个位置变为1)–相同的多个信号还没被处理的话,最后也就被处理一次

如果是实时信号的话,需要立即处理,而且接收到几次就要处理几次
这里的发送信号,本质是OS去修改task_struct的信号位图对应的比特位

–因为OS是进程的管理者,只有它有资格去修改task_struct内部的属性

信号的保存

为什么需要保存信号?–信号被进程接受后,并不一定立即处理,这时就需要有一个时间窗口
在这里插入图片描述
信号是几号,那它对应的block pending handler下标就是几

block里面为1,表示信号被阻塞

pending里面为1,表示信号未决

handler里面存的是处理方法的地址
信号保存的话,要保存它的block状态 pending状态

block
(阻塞,也叫屏蔽):被阻塞的信号产生时将保持在未决状态,直到进程解除对此信号的阻塞,才执行递达的动作 —信号还没产生,就可以先把这个信号block

–9号信号SIGKILL和19号信号SIGSTOP不能被阻塞

pending(信号未决):信号从产生到递达之间的状态

信号递达:实际执行信号的处理动作
对于1-31号的信号pending的位图,多久从1变成0:

在执行信号捕捉方法之前变 是先清0,再调用信号捕捉函数

Read more

OpenClaw(龙虾AI)Windows vs macOS 安装优缺点对比

OpenClaw(龙虾AI)Windows vs macOS 安装优缺点对比 OpenClaw(中文名"龙虾")是一款开源的个人AI助手/自动化平台[[12]]。以下是两个平台安装的详细对比: 🔧 安装方式对比 项目macOSWindows官方推荐方式终端一键脚本:curl -fsSL https://openclaw.ai/install.sh | bash管理员PowerShell运行:iwr -useb https://openclaw.ai/install.ps1 | iex [[1]]替代方案npm全局安装WSL2 + Ubuntu(官方更推荐)[[2]]依赖环境Node.js ≥22(可通过Homebrew自动安装)Node.js ≥22 + 可能需要nvm/Chocolatey安装耗时约5分钟[[1]]原生:10-15分钟;

By Ne0inhk

Flutter 三方库 path 的鸿蒙化适配指南 - 实现具备跨平台路径解析、合并与规范化处理的 IO 管理底座、支持端侧沙箱路径与通配符匹配实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 path 的鸿蒙化适配指南 - 实现具备跨平台路径解析、合并与规范化处理的 IO 管理底座、支持端侧沙箱路径与通配符匹配实战 前言 在进行 Flutter for OpenHarmony 开发时,处理文件路径是一项极其频繁且高风险的操作。鸿蒙系统基于 Unix 内核(路径分隔符为 /),但在处理来自不同平台的数据或生成特定的资源路径时,手动拼接字符串极易引发“双斜杠”错误或路径遍历漏洞。path 是 Dart 官方维护的权威路径处理库。本文将探讨如何在鸿蒙端构建极致、专业的 IO 寻址基础设施。 一、原直观解析 / 概念介绍 1.1 基础原理 该库建立在“平台感知(Platform-Aware)”的路径逻辑之上。它不仅仅是简单的字符串工具,它理解

By Ne0inhk
Flutter 组件 whitecodel_auto_link 适配鸿蒙 HarmonyOS 实战:交互式文本探针,构建信息流自动链接识别与极速预览架构

Flutter 组件 whitecodel_auto_link 适配鸿蒙 HarmonyOS 实战:交互式文本探针,构建信息流自动链接识别与极速预览架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 whitecodel_auto_link 适配鸿蒙 HarmonyOS 实战:交互式文本探针,构建信息流自动链接识别与极速预览架构 前言 在鸿蒙(OpenHarmony)生态迈向深度社交、企业办公及即时通讯全场景覆盖的背景下,如何将枯燥的长文本转化为具备可交互能力的“信息枢纽”,已成为提升用户操作效率的关键。在鸿蒙设备这类强调分布式协同与智慧感知的移动终端上,如果应用仅能显示纯文本,而无法识别其中的网址(URL)、邮箱(Email)或电话(Phone),用户就必须通过复杂的“长按、复制、切换应用、粘贴”链路来处理信息,这极大地割裂了鸿蒙系统的流转体验。 我们需要一种能够自动扫描文本特征、支持多维热点识别且具备高性能渲染能力的富文本处理引擎。 whitecodel_auto_link 为 Flutter 开发者引入了极其简便的长文本自动链接方案。它通过内置的高精度正则匹配矩阵,自动将文本中的特定识别域转化为可点击的高亮区域。在适配到鸿蒙

By Ne0inhk
Flutter for OpenHarmony: Flutter 三方库 intl_utils 自动化管理鸿蒙应用国际化多语言资源(零样板代码的多端适配)

Flutter for OpenHarmony: Flutter 三方库 intl_utils 自动化管理鸿蒙应用国际化多语言资源(零样板代码的多端适配)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在开发 OpenHarmony 面向全球市场的 App 时,国际化(i18n)是必经之路。虽然 Flutter 官方提供了 intl 库,但在实际项目中,手动维护 .arb 文件并生成代码非常繁琐。 intl_utils (配合 IDE 插件) 是业界公认的最佳实践方案。它能自动监听翻译文件的变更,并实时生成强类型的 Dart 调用代码,让国际化像使用普通变量一样简单安全。 一、核心工作流 保存触发 生成代码 强类型调用 pubspec.yaml (配置开启) l10n/*.arb (翻译源文件) intl_utils (自动生成) lib/generated/

By Ne0inhk