在 Linux 系统中，systemd 本身不会直接加载内核模块，但 systemd 可以通过其配套工具或与其他组件的协作间接触发内核模块的加载。以下是详细说明：
1. 内核模块的常规加载方式
内核模块（.ko 文件）通常通过以下方式加载：
- 手动加载:
sudo modprobe <模块名> # 推荐（自动处理依赖） 或 sudo insmod /path/to/module.ko - 启动时自动加载:
依赖以下机制：/etc/modules-load.d/*.conf
由systemd-modules-load.service读取并加载列出的模块。depmod+modprobe
通过依赖关系自动加载（如硬件检测触发）。
2. systemd 的角色
(1) systemd-modules-load.service
作用:
在系统启动早期阶段，读取/etc/modules-load.d/、/usr/lib/modules-load.d/下的.conf文件，并调用modprobe加载其中列出的模块。配置文件示例:
创建/etc/modules-load.d/my_modules.conf，内容为：# 每行一个模块名 nf_conntrack vboxdrv验证服务状态:
systemctl status systemd-modules-load
(2) Hardware Trigger (udev)
- udev规则:
当硬件设备被检测到时，udev（与systemd集成）可能根据/usr/lib/udev/rules.d/或/etc/udev/rules.d/中的规则动态加载对应驱动模块。 - 示例规则:
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1234", RUN+="/sbin/modprobe usb-storage"
(3) Systemd Service Dependencies
如果某个服务（如 docker.service）依赖特定内核模块，systemd会在启动该服务前通过 modprobe隐式加载所需模块。
3.如何确认模块是否被自动加载？
(1)查看已加载模块
lsmod #列出所有已加载模块
lsmod | grep <模块名> #检查特定模块
(2)检查日志
journalctl -u systemd-modules-load --boot #查看modules-load服务的日志
dmesg | grep <模块名> #内核日志中搜索模块加载记录
4.常见问题排查
(1)模块未按预期加载
- 确认配置文件路径正确:
确保.conf文件位于/etc/modules-load.d/。 - 检查拼写错误:
使用modinfo <module>验证模块是否存在。
(2)屏蔽不需要的模块
禁止特定模块自动加载：
echo "blacklist <module>" > /etc/modprobe.d/blacklist.conf
总结
| 行为 | 是否由 systemd直接控制? |
|---|---|
读取 /etc/modules-load.d/ |
✅ (systemd-modules-load.service) |
| 响应硬件事件动态加载 | ❌（由 udev处理） |
| 服务依赖的隐式加载 | ❌（由 modprobe完成） |
如果需要完全控制内核模块的加载流程，需结合配置文件和底层工具（如 modprobe, udevadm)进行管理。
内容由零声教学AI助手提供，问题来源于学员提问
 {
using Type = std::decay_t;
if con...](https://linuxcpp.0voice.com/zb_users/upload/2023/05/202305162215084030351.png)
