morgan/systemd
1
0
Fork 0
mirror of https://github.com/morgan9e/systemd synced 2026-04-15 00:47:10 +09:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
systemd/units/modprobe@.service

36 lines
1.3 KiB
SYSTEMD
Raw Permalink Normal View History

license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 13:23:58 +09:00
# SPDX-License-Identifier: LGPL-2.1-or-later
units: Split modprobing out into a separate service unit Devices referred to by `DeviceAllow=` sandboxing are resolved into their corresponding major numbers when the unit is loaded by looking at `/proc/devices`. If a reference is made to a device which is not yet available, the `DeviceAllow` is ignored and the unit's processes cannot access that device. In both logind and nspawn, we have `DeviceAllow=` lines, and `modprobe` in `ExecStartPre=` to load some kernel modules. Those kernel modules cause device nodes to become available when they are loaded: the device nodes may not exist when the unit itself is loaded. This means that the unit's processes will not be able to access the device since the `DeviceAllow=` will have been resolved earlier and denied it. One way to fix this would be to re-evaluate the available devices and re-apply the policy to the cgroup, but this cannot work atomically on cgroupsv1. So we fall back to a second approach: instead of running `modprobe` via `ExecStartPre`, we move this out to a separate unit and order it before the units which want the module. Closes #14322. Fixes: #13943.
2020-01-07 14:33:29 +00:00
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
units: add a longer comment to modprobe@.service explaining when to use it
2025-01-23 14:47:03 +01:00
# This unit loads a specific kernel module explicitly and synchronizes on its
# initialization to be complete. This unit should only be used as dependency
# if automatic module loading cannot be used for a module, i.e. in exceptional
# cases. These cases may include:
#
# 1. The primary API exposed by the module is a device node that is normally
# managed by systemd-tmpfiles-setup-dev-early.service (and thus auto-loading
# is generally supported), but some service already needs the functionality
# during even earlier boot.
#
# 2. The primary API exposed by the module is some directory in /sys/, /proc/
# or configfs, where simple access generally is not sufficient to load the
# module.
units: Split modprobing out into a separate service unit Devices referred to by `DeviceAllow=` sandboxing are resolved into their corresponding major numbers when the unit is loaded by looking at `/proc/devices`. If a reference is made to a device which is not yet available, the `DeviceAllow` is ignored and the unit's processes cannot access that device. In both logind and nspawn, we have `DeviceAllow=` lines, and `modprobe` in `ExecStartPre=` to load some kernel modules. Those kernel modules cause device nodes to become available when they are loaded: the device nodes may not exist when the unit itself is loaded. This means that the unit's processes will not be able to access the device since the `DeviceAllow=` will have been resolved earlier and denied it. One way to fix this would be to re-evaluate the available devices and re-apply the policy to the cgroup, but this cannot work atomically on cgroupsv1. So we fall back to a second approach: instead of running `modprobe` via `ExecStartPre`, we move this out to a separate unit and order it before the units which want the module. Closes #14322. Fixes: #13943.
2020-01-07 14:33:29 +00:00
[Unit]
units: tweaks to modprobe@.service Let's use uppercase wording in the description string, like we usually do. Let's allow using this service in early boot. If it's pulled into the initial transaction it's better to finish loading this before sysinit.target. Don't bother with this in containers that lack CAP_SYS_MODULE
2020-01-07 18:54:24 +01:00
Description=Load Kernel Module %i
DefaultDependencies=no
Before=sysinit.target
units: Split modprobing out into a separate service unit Devices referred to by `DeviceAllow=` sandboxing are resolved into their corresponding major numbers when the unit is loaded by looking at `/proc/devices`. If a reference is made to a device which is not yet available, the `DeviceAllow` is ignored and the unit's processes cannot access that device. In both logind and nspawn, we have `DeviceAllow=` lines, and `modprobe` in `ExecStartPre=` to load some kernel modules. Those kernel modules cause device nodes to become available when they are loaded: the device nodes may not exist when the unit itself is loaded. This means that the unit's processes will not be able to access the device since the `DeviceAllow=` will have been resolved earlier and denied it. One way to fix this would be to re-evaluate the available devices and re-apply the policy to the cgroup, but this cannot work atomically on cgroupsv1. So we fall back to a second approach: instead of running `modprobe` via `ExecStartPre`, we move this out to a separate unit and order it before the units which want the module. Closes #14322. Fixes: #13943.
2020-01-07 14:33:29 +00:00
Documentation=man:modprobe(8)
units: tweaks to modprobe@.service Let's use uppercase wording in the description string, like we usually do. Let's allow using this service in early boot. If it's pulled into the initial transaction it's better to finish loading this before sysinit.target. Don't bother with this in containers that lack CAP_SYS_MODULE
2020-01-07 18:54:24 +01:00
ConditionCapability=CAP_SYS_MODULE
condition: add new ConditionKernelModuleLoaded= This introduces a new unit condition check: that matches if a specific kmod module is allowed. This should be generally useful, but there's one usecase in particular: we can optimize modprobe@.service with this and avoid forking out a bunch of modprobe requests during boot for the same kmods. Checking if a kernel module is loaded is more complicated than just checking if /sys/module/$MODULE/ exists, since kernel modules typically take a while to initialize and we must check that this is complete (by checking if the sysfs attr "initstate" is "live").
2024-11-28 13:00:34 +01:00
ConditionKernelModuleLoaded=!%i
units: remove the restart limit on the modprobe@.service They are various cases where the same module might be repeatedly loaded in a short time frame, for example if a service depending on a module keep restarting, or if many instances of such service get started at the same time. If this happend the modprobe@.service instance will be marked as failed because it hit the restart limit. Overall it doesn't seems to make much sense to have a restart limit on the modprobe service so just disable it. Fixes: #23742
2022-06-15 13:12:46 +02:00
StartLimitIntervalSec=0
units: Split modprobing out into a separate service unit Devices referred to by `DeviceAllow=` sandboxing are resolved into their corresponding major numbers when the unit is loaded by looking at `/proc/devices`. If a reference is made to a device which is not yet available, the `DeviceAllow` is ignored and the unit's processes cannot access that device. In both logind and nspawn, we have `DeviceAllow=` lines, and `modprobe` in `ExecStartPre=` to load some kernel modules. Those kernel modules cause device nodes to become available when they are loaded: the device nodes may not exist when the unit itself is loaded. This means that the unit's processes will not be able to access the device since the `DeviceAllow=` will have been resolved earlier and denied it. One way to fix this would be to re-evaluate the available devices and re-apply the policy to the cgroup, but this cannot work atomically on cgroupsv1. So we fall back to a second approach: instead of running `modprobe` via `ExecStartPre`, we move this out to a separate unit and order it before the units which want the module. Closes #14322. Fixes: #13943.
2020-01-07 14:33:29 +00:00
[Service]
Type=oneshot
units: modprobe@.service: don't unescape instance name modprobe treats "-" and "_" interchangeably, thereby avoiding frequent errors because some module names contain dashes and others underscores. Because modprobe@.service unescapes the instance name, an attempt to start "modprobe@dm-crypt.service" will run "modprobe -abq dm/crypt", which is doomed to fail. "modprobe@dm_crypt.service" will work as expected. Thus unescaping the instance name has surprising side effects. Use "%i" instead.
2023-10-20 16:25:15 +02:00
ExecStart=-/sbin/modprobe -abq %i
Reference in New Issue Copy Permalink