MSYS2修改国内源
1. 打开配置文件目录
进入MSYS2安装目录,例如C:\msys64,打开路径 C:\msys64\etc\pacman.d.
2. 修改镜像源文件
在该目录下找到以下文件,并分别进行修改:
修改 mirrorlist.msys
将以下内容添加到文件顶部:
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/msys/$arch |
修改 mirrorlist.mingw32
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686 |
修改 mirrorlist.mingw64
1 | Server = https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/x86_64 |
(可选)修改其他文件
如果需要支持 ucrt64 或 _clang_,可参考以下示例
1 | # mirrorlist.ucrt64 |
3. 更新MSYS2
完成上述修改后,运行以下命令更新系统:
1 | pacman -Syu |
注意事项
- 确保每个文件的顶部添加了正确的镜像地址。
- 如果更新过程中遇到问题,可尝试删除 .git 文件夹后重新初始化。
通过以上步骤,MSYS2 的更新速度将显著提升。
Linux4.4内核配置
[Linux-4.4-x86_64 内核配置选项简介 金步国] (jinbuguo.com)
Systemd 服务管理
Systemd 服务管理
Systemd 概述
Systemd 简介
Systemd 是一系列工具的集合,其作用也远远不仅是启动操作系统,它还接管了后台服务、结束、状态查询,以及日志归档、设备管理、电源管理、定时任务等许多职责,并支持通过特定事件(如插入特定 USB 设备)和特定端口数据触发的 On-demand(按需)任务。
Systemd 的后台服务还有一个特殊的身份——它是系统中 PID 值为 1 的进程。
- 更少的进程
Systemd 提供了服务按需启动的能力,使得特定的服务只有在真正被请求时才启动。
- 允许更多的进程并行启动
在 SysV-init 时代,将每个服务项目编号依次执行启动脚本。Ubuntu 的 Upstart 解决了没有直接依赖的启动之间的并行启动。而 Systemd 通过 Socket 缓存、DBus 缓存和建立临时挂载点等方法进一步解决了启动进程之间的依赖,做到了所有系统服务并发启动。对于用户自定义的服务,Systemd 允许配置其启动依赖项目,从而确保服务按必要的顺序运行。
- 使用 CGroup 跟踪和管理进程的生命周期
在 Systemd 之前的主流应用管理服务都是使用进程树来跟踪应用的继承关系的,而进程的父子关系很容易通过两次 fork 的方法脱离。
而 Systemd 则提供通过 CGroup 跟踪进程关系,弥补了这个缺漏。通过 CGroup 不仅能够实现服务之间访问隔离,限制特定应用程序对系统资源的访问配额,还能更精确地管理服务的生命周期。
- 统一管理服务日志
Systemd 是一系列工具的集合,包括了一个专用的系统日志管理服务:Journald。这个服务的设计初衷是克服现有 Syslog 服务的日志内容易伪造和日志格式不统一等缺点,Journald 用二进制格式保存所有的日志信息,因而日志内容很难被手工伪造。Journald 还提供了一个 journalctl 命令来查看日志信息,这样就使得不同服务输出的日志具有相同的排版格式,便于数据的二次处理。
Systemd 架构
![[Systemd服务管理/IMG-20260205160657597.png]]
Systemd 的 Unit 文件
Systemd 可以管理所有系统资源,不同的资源统称为 Unit(单位)。
在 Systemd 的生态圈中,Unit 文件统一了过去各种不同系统资源配置格式,例如服务的启/停、定时任务、设备自动挂载、网络配置、虚拟内存配置等。而 Systemd 通过不同的文件后缀来区分这些配置文件。
Systemd 支持的 12 种 Unit 文件类型
- .automount:用于控制自动挂载文件系统,相当于 SysV-init 的 autofs 服务
- .device:对于 /dev 目录下的设备,主要用于定义设备之间的依赖关系
- .mount:定义系统结构层次中的一个挂载点,可以替代过去的 /etc/fstab 配置文件
- .path:用于监控指定目录或文件的变化,并触发其它 Unit 运行
- .scope:这种 Unit 文件不是用户创建的,而是 Systemd 运行时产生的,描述一些系统服务的分组信息
- .service:封装守护进程的启动、停止、重启和重载操作,是最常见的一种 Unit 文件
- .slice:用于表示一个 CGroup 的树,通常用户不会自己创建这样的 Unit 文件
- .snapshot:用于表示一个由 systemctl snapshot 命令创建的 Systemd Units 运行状态快照
- .socket:监控来自于系统或网络的数据消息,用于实现基于数据自动触发服务启动
- .swap:定义一个用户做虚拟内存的交换分区
- .target:用于对 Unit 文件进行逻辑分组,引导其它 Unit 的执行。它替代了 SysV-init 运行级别的作用,并提供更灵活的基于特定设备事件的启动方式
- .timer:用于配置在特定时间触发的任务,替代了 Crontab 的功能
Systemd 目录
Unit 文件按照 Systemd 约定,应该被放置指定的三个系统目录之一中。这三个目录是有优先级的,如下所示,越靠上的优先级越高。因此,在三个目录中有同名文件的时候,只有优先级最高的目录里的那个文件会被使用。
- /etc/systemd/system:系统或用户自定义的配置文件
- /run/systemd/system:软件运行时生成的配置文件
- /usr/lib/systemd/system:系统或第三方软件安装时添加的配置文件。
- CentOS 7:Unit 文件指向该目录
- ubuntu 16:被移到了 /lib/systemd/system
Systemd 默认从目录 /etc/systemd/system/ 读取配置文件。但是,里面存放的大部分文件都是符号链接,指向目录 /usr/lib/systemd/system/,真正的配置文件存放在那个目录。
Unit 和 Target
Unit 是 Systemd 管理系统资源的基本单元,可以认为每个系统资源就是一个 Unit,并使用一个 Unit 文件定义。在 Unit 文件中需要包含相应服务的描述、属性以及需要运行的命令。
Target 是 Systemd 中用于指定系统资源启动组的方式,相当于 SysV-init 中的运行级别。
简单说,Target 就是一个 Unit 组,包含许多相关的 Unit 。启动某个 Target 的时候,Systemd 就会启动里面所有的 Unit。从这个意义上说,Target 这个概念类似于”状态点”,启动某个 Target 就好比启动到某种状态。
Systemd Service Unit
Unit 文件结构
1 | [Unit] |
如下所示,Systemd 服务的 Unit 文件可以分为三个配置区段:
- Unit 和 Install 段:所有 Unit 文件通用,用于配置服务(或其它系统资源)的描述、依赖和随系统启动的方式
- Service 段:服务(Service)类型的 Unit 文件(后缀为 .service)特有的,用于定义服务的具体管理和操作方法
Unit 段
- Description:描述这个 Unit 文件的信息
- Documentation:指定服务的文档,可以是一个或多个文档的 URL 路径
- Requires:依赖的其它 Unit 列表,列在其中的 Unit 模板会在这个服务启动时的同时被启动。并且,如果其中任意一个服务启动失败,这个服务也会被终止
- Wants:与 Requires 相似,但只是在被配置的这个 Unit 启动时,触发启动列出的每个 Unit 模块,而不去考虑这些模板启动是否成功
- After:与 Requires 相似,但是在后面列出的所有模块全部启动完成以后,才会启动当前的服务
- Before:与 After 相反,在启动指定的任务一个模块之间,都会首先确证当前服务已经运行
- Binds To:与 Requires 相似,失败时失败,成功时成功,但是在这些模板中有任意一个出现意外结束或重启时,这个服务也会跟着终止或重启
- Part Of:一个 Bind To 作用的子集,仅在列出的任务模块失败或重启时,终止或重启当前服务,而不会随列出模板的启动而启动
- OnFailure:当这个模板启动失败时,就会自动启动列出的每个模块
- Conflicts:与这个模块有冲突的模块,如果列出的模块中有已经在运行的,这个服务就不能启动,反之亦然
Install 段
这部分配置的目标模块通常是特定运行目标的 .target 文件,用来使得服务在系统启动时自动运行。这个区段可以包含三种启动约束:
- WantedBy:和 Unit 段的 Wants 作用相似,只有后面列出的不是服务所依赖的模块,而是依赖当前服务的模块。它的值是一个或多个 Target,当前 Unit 激活时(enable)符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .wants 后缀构成的子目录中,如 “/etc/systemd/system/multi-user.target.wants/“
1 | # find /etc/systemd/system/* -type d |
- RequiredBy:和 Unit 段的 Wants 作用相似,只有后面列出的不是服务所依赖的模块,而是依赖当前服务的模块。它的值是一个或多个 Target,当前 Unit 激活时,符号链接会放入 /etc/systemd/system 目录下面以 <Target 名> + .required 后缀构成的子目录中
- Also:当前 Unit enable/disable 时,同时 enable/disable 的其他 Unit
- Alias:当前 Unit 可用于启动的别名
SysV-init 运行级别与 Systemd Target 对应的 Unit 文件
| SysV-Init Level | Systemd Target | Note |
|---|---|---|
| 0 | runlevel0.target -> poweroff.target | 关闭系统 |
| 1 | runlevel1.target -> rescue.target | 单用户模式 |
| 2 | runlevel2.target -> multi-user.target | 用户定义/域特性运行级别,默认等同于级别3 |
| 3 | runlevel3.target -> multi-user.target | 多用户模式 |
| 4 | runlevel4.target -> multi-user.target | 用户定义/域特定运行级别,默认等同于级别3 |
| 5 | runlevel5.target -> graphical.target | 多用户, 图形模式 |
| 6 | runlevel6.target -> reboot.target | 重启 |
| emergency | emergency.target | 急救模式 |
通过 systemctl list-units –type=target 命令可以获取当前正在使用的运行目标
1 | # systemctl list-units --type=target |
Service 段
用来 Service 的配置,只有 Service 类型的 Unit 才有这个区块。它的主要字段分为服务生命周期和服务上下文配置两个方面。
服务生命周期控制相关
- Type:定义启动时的进程行为,它有以下几种值:
- Type=simple:默认值,执行ExecStart指定的命令,启动主进程
- Type=forking:以 fork 方式从父进程创建子进程,创建后父进程会立即退出
- Type=oneshot:一次性进程,Systemd 会等当前服务退出,再继续往下执行
- Type=dbus:当前服务通过D-Bus启动
- Type=notify:当前服务启动完毕,会通知Systemd,再继续往下执行
- Type=idle:若有其他任务执行完毕,当前服务才会运行
- RemainAfterExit:值为 true 或 false(默认)。当配置为 true 时,Systemd 只会负责启动服务进程,之后即便服务进程退出了,Systemd 也仍然会认为这个服务还在运行中。这个配置主要是提供给一些并非常驻内存,而是启动注册后立即退出,然后等待消息按需启动的特殊类型服务使用的。
- ExecStart:启动当前服务的命令
- ExecStartPre:启动当前服务之前执行的命令
- ExecStartPost:启动当前服务之后执行的命令
- ExecReload:重启当前服务时执行的命令
- ExecStop:停止当前服务时执行的命令
- ExecStopPost:停止当其服务之后执行的命令
- RestartSec:自动重启当前服务间隔的秒数
- Restart:定义何种情况 Systemd 会自动重启当前服务,可能的值包括 always(总是重启)、on-success、on-failure、on-abnormal、on-abort、on-watchdog
- TimeoutStartSec:启动服务时等待的秒数,这一配置对于使用 Docker 容器而言显得尤为重要,因其第一次运行时可能需要下载镜像,严重延时会容易被 Systemd 误判为启动失败杀死。通常,对于这种服务,将此值指定为 0,从而关闭超时检测
- TimeoutStopSec:停止服务时的等待秒数,如果超过这个时间仍然没有停止,Systemd 会使用 SIGKILL 信号强行杀死服务的进程
服务上下文配置相关
- Environment:为服务指定环境变量
- EnvironmentFile:指定加载一个包含服务所需的环境变量的列表的文件,文件中的每一行都是一个环境变量的定义
- Nice:服务的进程优先级,值越小优先级越高,默认为 0。其中 -20 为最高优先级,19 为最低优先级
- WorkingDirectory:指定服务的工作目录
- RootDirectory:指定服务进程的根目录(/ 目录)。如果配置了这个参数,服务将无法访问指定目录以外的任何文件
- User:指定运行服务的用户
- Group:指定运行服务的用户组
- MountFlags:服务的 Mount Namespace 配置,会影响进程上下文中挂载点的信息,即服务是否会继承主机上已有挂载点,以及如果服务运行执行了挂载或卸载设备的操作,是否会真实地在主机上产生效果。可选值为 shared、slaved 或 private
- shared:服务与主机共用一个 Mount Namespace,继承主机挂载点,且服务挂载或卸载设备会真实地反映到主机上
- slave:服务使用独立的 Mount Namespace,它会继承主机挂载点,但服务对挂载点的操作只有在自己的 Namespace 内生效,不会反映到主机上
- private:服务使用独立的 Mount Namespace,它在启动时没有任何任何挂载点,服务对挂载点的操作也不会反映到主机上
- LimitCPU / LimitSTACK / LimitNOFILE / LimitNPROC 等:限制特定服务的系统资源量,例如 CPU、程序堆栈、文件句柄数量、子进程数量等
注意:如果在 ExecStart、ExecStop 等属性中使用了 Linux 命令,则必须要写出完整的绝对路径。对于 ExecStartPre 和 ExecStartPost 辅助命令,若前面有个 “-” 符号,表示忽略这些命令的出错。因为有些 “辅助” 命令本来就不一定成功,比如尝试清空一个文件,但文件可能不存在。
Unit 文件占位符和模板
Unit 文件占位符
在 Unit 文件中,有时会需要使用到一些与运行环境有关的信息,例如节点 ID、运行服务的用户等。这些信息可以使用占位符来表示,然后在实际运行被动态地替换实际的值。
- %n:完整的 Unit 文件名字,包括 .service 后缀名
- %p:Unit 模板文件名中 @ 符号之前的部分,不包括 @ 符号
- %i:Unit 模板文件名中 @ 符号之后的部分,不包括 @ 符号和 .service 后缀名
- %t:存放系统运行文件的目录,通常是 “run”
- %u:运行服务的用户,如果 Unit 文件中没有指定,则默认为 root
- %U:运行服务的用户 ID
- %h:运行服务的用户 Home 目录,即 %{HOME} 环境变量的值
- %s:运行服务的用户默认 Shell 类型,即 %{SHELL} 环境变量的值
- %m:实际运行节点的 Machine ID,对于运行位置每个的服务比较有用
- %b:Boot ID,这是一个随机数,每个节点各不相同,并且每次节点重启时都会改变
- %H:实际运行节点的主机名
- %v:内核版本,即
uname -r命令输出的内容 - %%:在 Unit 模板文件中表示一个普通的百分号
Unit 模板
在现实中,往往有一些应用需要被复制多份运行。例如,用于同一个负载均衡器分流的多个服务实例,或者为每个 SSH 连接建立一个独立的 sshd 服务进程。
Unit 模板文件的写法与普通的服务 Unit 文件基本相同,不过 Unit 模板的文件名是以 @ 符号结尾的。通过模板启动服务实例时,需要在其文件名的 @ 字符后面附加一个参数字符串。
示例:apache@.service
apache@.service 模板
1 | [Unit] |
启动 Unit 模板的服务实例
在服务启动时需要在 @ 后面放置一个用于区分服务实例的附加字符参数,通常这个参数用于监控的端口号或控制台 TTY 编译号。
1 | systemctl start apache@8080.service |
Systemd 在运行服务时,总是会先尝试找到一个完整匹配的 Unit 文件,如果没有找到,才会尝试选择匹配模板。例如上面的命令,System 首先会在约定的目录下寻找名为 apache@8080.service 的文件,如果没有找到,而文件名中包含 @ 字符,它就会尝试去掉后缀参数匹配模板文件。对于 apache@8080.service,systemd 会找到 apache@.service 模板文件,并通过这个模板文件将服务实例化。
Systemd 的资源管理
Systemctl 命令
1 | # systemctl --help |
Unit 管理
查看当前系统的所有 Unit
1 | # 列出正在运行的 Unit |
查看 Unit 的状态
- enabled:已建立启动链接
- disabled:没建立启动链接
- static:该配置文件没有 [Install] 部分(无法执行),只能作为其他配置文件的依赖
- masked:该配置文件被禁止建立启动链接
1 | # 显示系统状态 |
Unit 的管理
1 | # 立即启动一个服务 |
查看 Unit 的依赖关系
1 | # 列出一个 Unit 的所有依赖,默认不会列出 target 类型 |
服务的生命周期
当一个新的 Unit 文件被放入 /etc/systemd/system/ 或 /usr/lib/systemd/system/ 目录中时,它是不会被自识识别的。
服务的激活
- systemctl enable:在 /etc/systemd/system/ 建立服务的符号链接,指向 /usr/lib/systemd/system/ 中
- systemctl start:依次启动定义在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令
服务的启动和停止
- systemctl start:依次启动定义在 Unit 文件中的 ExecStartPre、ExecStart 和 ExecStartPost 命令
- systemctl stop:依次停止定义在 Unit 文件中的 ExecStopPre、ExecStop 和 ExecStopPost 命令
- systemctl restart:重启服务
- systemctl kill:立即杀死服务
服务的开机启动和取消
- systemctl enable:除了激活服务以外,也可以置服务为开机启动
- systemctl disable:取消服务的开机启动
服务的修改和移除
- systemctl daemon-reload:Systemd 会将 Unit 文件的内容写到缓存中,因此当 Unit 文件被更新时,需要告诉 Systemd 重新读取所有的 Unit 文件
- systemctl reset-failed:移除标记为丢失的 Unit 文件。在删除 Unit 文件后,由于缓存的关系,即使通过 daemon-reload 更新了缓存,在 list-units 中依然会显示标记为 not-found 的 Unit。
Target 管理
Target 就是一个 Unit 组,包含许多相关的 Unit 。启动某个 Target 的时候,Systemd 就会启动里面所有的 Unit。
在传统的 SysV-init 启动模式里面,有 RunLevel 的概念,跟 Target 的作用很类似。不同的是,RunLevel 是互斥的,不可能多个 RunLevel 同时启动,但是多个 Target 可以同时启动。
1 | # 查看当前系统的所有 Target |
Target 与 SysV-init 进程的主要区别:
- 默认的 RunLevel(在 /etc/inittab 文件设置)现在被默认的 Target 取代,位置是 /etc/systemd/system/default.target,通常符号链接到graphical.target(图形界面)或者multi-user.target(多用户命令行)。
- 启动脚本的位置,以前是 /etc/init.d 目录,符号链接到不同的 RunLevel 目录 (比如 /etc/rc3.d、/etc/rc5.d 等),现在则存放在 /lib/systemd/system 和 /etc/systemd/system 目录。
- 配置文件的位置,以前 init 进程的配置文件是 /etc/inittab,各种服务的配置文件存放在 /etc/sysconfig 目录。现在的配置文件主要存放在 /lib/systemd 目录,在 /etc/systemd 目录里面的修改可以覆盖原始设置。
日志管理
Systemd 通过其标准日志服务 Journald 提供的配套程序 journalctl 将其管理的所有后台进程打印到 std:out(即控制台)的输出重定向到了日志文件。
Systemd 的日志文件是二进制格式的,必须使用 Journald 提供的 journalctl 来查看,默认不带任何参数时会输出系统和所有后台进程的混合日志。
默认日志最大限制为所在文件系统容量的 10%,可以修改 /etc/systemd/journald.conf 中的 SystemMaxUse 来指定该最大限制。
1 | # 查看所有日志(默认情况下 ,只保存本次启动的日志) |
Systemd 工具集
- systemctl:用于检查和控制各种系统服务和资源的状态
- bootctl:用于查看和管理系统启动分区
- hostnamectl:用于查看和修改系统的主机名和主机信息
- journalctl:用于查看系统日志和各类应用服务日志
- localectl:用于查看和管理系统的地区信息
- loginctl:用于管理系统已登录用户和 Session 的信息
- machinectl:用于操作 Systemd 容器
- timedatectl:用于查看和管理系统的时间和时区信息
- systemd-analyze:显示此次系统启动时运行每个服务所消耗的时间,可以用于分析系统启动过程中的性能瓶颈
- systemd-ask-password:辅助性工具,用星号屏蔽用户的任意输入,然后返回实际输入的内容
- systemd-cat:用于将其他命令的输出重定向到系统日志
- systemd-cgls:递归地显示指定 CGroup 的继承链
- systemd-cgtop:显示系统当前最耗资源的 CGroup 单元
- systemd-escape:辅助性工具,用于去除指定字符串中不能作为 Unit 文件名的字符
- systemd-hwdb:Systemd 的内部工具,用于更新硬件数据库
- systemd-delta:对比当前系统配置与默认系统配置的差异
- systemd-detect-virt:显示主机的虚拟化类型
- systemd-inhibit:用于强制延迟或禁止系统的关闭、睡眠和待机事件
- systemd-machine-id-setup:Systemd 的内部工具,用于给 Systemd 容器生成 ID
- systemd-notify:Systemd 的内部工具,用于通知服务的状态变化
- systemd-nspawn:用于创建 Systemd 容器
- systemd-path:Systemd 的内部工具,用于显示系统上下文中的各种路径配置
- systemd-run:用于将任意指定的命令包装成一个临时的后台服务运行
- systemd-stdio-bridge:Systemd 的内部工具,用于将程序的标准输入输出重定向到系统总线
- systemd-tmpfiles:Systemd 的内部工具,用于创建和管理临时文件目录
- systemd-tty-ask-password-agent:用于响应后台服务进程发出的输入密码请求
systemctl
1 | # 重启系统 |
systemd-analyze
1 | # 查看启动耗时 |
hostnamectl
1 | # 显示当前主机的信息 |
timedatectl
1 | # 查看当前时区设置 |
loginctl
1 | # 列出当前 session |
systemd-ask-password
1 | $ PASSWORD=$(systemd-ask-password "Input Your Password:") |
systemd-run
systemd-run 可以将一个指定的操作变成后台运行的服务。它的效果似乎与直接在命令后加上表示后台运行的 & 符号很相似。然而,它让命令成为服务还意味着,它的生命周期将由 Systemd 控制。具体来说,包括以下好处:
- 服务的生命周期由 Systemd 接管,不会随着启动它的控制台关闭而结束
- 可以通过 systemctl 工具管理服务的状态
- 可以通过 journalctl 工具查看和管理服务的日志信息
- 可以通过 Systemd 提供的方法限制服务的 CPU、内存、磁盘 IO 等系统资源的使用情况。