IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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
This reverts commit 9cbf1e58f9.
The presence of /sys/module/%I directory can't be used to assert that the load
of a given module is complete and therefore the call to modprobe(8) can be
skipped. Indeed this directory is created before the init() function of the
module is called.
Users of modprobe@.service needs to be sure that once this service returns the
module is fully operational.
Possible alternative to #14819.
For me, setting RemainAfterExit=yes would be OK, but if people think that it
might cause issues, then this could be a reasonable alternative that still
let's us skip the invocation of the separate binary.
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
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.
