Services with RootImage hitting the restart limit lead to failed modprobe@dm_verity.service #23742
Labels
pid1
please-submit-as-pr
portable
Anything to do with systemd-portable and portablectl and portables
Comments
yuwata
added
pid1
portable
I think this is reasonable. @poettering @bluca WDYT? |
@AlbanBedel Could you provide a PR? |
AlbanBedel
added a commit
to AlbanBedel/systemd
that referenced
this issue
Jun 15, 2022
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: systemd#23742
keszybz
pushed a commit
that referenced
this issue
Jun 21, 2022
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
tewarid
pushed a commit
to tewarid/systemd
that referenced
this issue
Aug 23, 2022
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: systemd#23742 (cherry picked from commit 9625350)
bluca
pushed a commit
to bluca/systemd
that referenced
this issue
Jan 27, 2023
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: systemd#23742 (cherry picked from commit 9625350) (cherry picked from commit 8539a62)
Werkov
pushed a commit
to Werkov/systemd
that referenced
this issue
Nov 1, 2023
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: systemd#23742 (cherry picked from commit 9625350)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
This version is a bit older but it is on an embedded system where I can't easily switch to a newer version. From my analysis of the related code and unit files I strongly believe this bug is still present in the latest version.
Unexpected behaviour you saw
Steps to reproduce the problem
Looking at the code, units with a RootImage automatically get several modprobe@ added as dependency, which lead to this problem if the respective module doesn't exists. The modprobe@ unit in itself doesn't fail when the module is missing as the command is allowed to fail, but it then hit the restart limit because the parent service keep restarting it.
MR #15027 used to mitigate this problem when the modules can be loaded but it doesn't help when the module can't get loaded. But it was reverted anyways. On the other hand using
RemainAfterExit=yesin modprobe@.service as was suggested in #14819 do solve this problem. Removing the restart limit in the modprobe service would be another solution.The text was updated successfully, but these errors were encountered: