[Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail
Alfonso Sanchez-Beato
1982462 at bugs.launchpad.net
Thu Aug 4 16:10:21 UTC 2022
I have tested a modified systemd-pstore.service in UC20 (focal based)
adding:
[Unit]
After=modprobe at efi_pstore.service modprobe at mtdpstore.service modprobe at chromeos_pstore.service modprobe at ramoops.service modprobe at pstore_zone.service modprobe at pstore_blk.service
Wants=modprobe at efi_pstore.service modprobe at mtdpstore.service modprobe at chromeos_pstore.service modprobe at ramoops.service modprobe at pstore_zone.service modprobe at pstore_blk.service
As a result I get failures in the services trying to load modules for
pstore, for instance:
ubuntu at ubuntu:~$ sudo systemctl status modprobe at mtdpstore.service
● modprobe at mtdpstore.service - Load Kernel Module mtdpstore
Loaded: loaded (/lib/systemd/system/modprobe at .service; static; vendor preset: enabled)
Active: inactive (dead) since Thu 2022-08-04 15:59:31 UTC; 25s ago
Docs: man:modprobe(8)
Process: 400 ExecStart=/sbin/modprobe -abq mtdpstore (code=exited, status=1/FAILURE)
Main PID: 400 (code=exited, status=1/FAILURE)
Aug 04 15:59:31 ubuntu systemd[1]: modprobe at mtdpstore.service: Succeeded.
Aug 04 15:59:31 ubuntu systemd[1]: Finished Load Kernel Module mtdpstore.
Which is fine, but there is the potential of too many successive restart
of these services, which would result in
https://github.com/systemd/systemd/issues/23742. To prevent this,
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1
should be included in the next systemd focal SRU.
** Bug watch added: github.com/systemd/systemd/issues #23742
https://github.com/systemd/systemd/issues/23742
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462
Title:
Some modprobe loading services requested by the pstore service fail
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
New
Status in systemd source package in Jammy:
Triaged
Status in systemd source package in Kinetic:
Fix Released
Bug description:
[Impact]
It has been detected that some modprobe services fail on UC22 after
the jammy upgrade 249.11-0ubuntu3.4:
$ systemctl --system --no-ask-password --no-pager list-units --state=failed
Failed units:
UNIT LOAD ACTIVE SUB DESCRIPTION
● modprobe at chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore
● modprobe at efi_pstore.service loaded failed failed Load Kernel Module efi_pstore
● modprobe at mtdpstore.service loaded failed failed Load Kernel Module mtdpstore
● modprobe at pstore_blk.service loaded failed failed Load Kernel Module pstore_blk
● modprobe at pstore_zone.service loaded failed failed Load Kernel Module pstore_zone
● modprobe at ramoops.service loaded failed failed Load Kernel Module ramoops
This happens because of some changes to systemd-pstore.service that
now has:
After=modprobe at efi_pstore.service modprobe at mtdpstore.service modprobe at chromeos_pstore.service modprobe at ramoops.service modprobe at pstore_zone.service modprobe at pstore_blk.service
Wants=modprobe at efi_pstore.service modprobe at mtdpstore.service modprobe at chromeos_pstore.service modprobe at ramoops.service modprobe at pstore_zone.service modprobe at pstore_blk.service
This causes too many tries of the modprobe services, that fail in the
end with
Jul 20 09:02:39 ubuntu systemd[1]: modprobe at chromeos_pstore.service:
Start request repeated too quickly.
Although we have seen this only on UC22, it potentially can affect
classic systems as well, as systemd-pstore.service is re-tried there a
few times too. See https://github.com/snapcore/core-base/issues/72 for
more details.
A fix for this is available upstream:
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1
[Test Plan]
Start the device and check that there is no modprobe-pstore related
failed service. This is racy, so a few tries will be needed to make
sure things are fine.
[Where problems could occur]
The modprobe services are usually dependencies from other services, so
it should be fine if the retry behavior is controlled by those other
services. Risk should be small. If something goes wrong we might see a
lot of restarts for these services.
[Other Info]
Testing should happen on UC22 too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+subscriptions
More information about the foundations-bugs
mailing list