Skip to content

openrc: retry initialisation if it fails#63

Open
luke-jr wants to merge 1 commit into
vaeth:mainfrom
luke-jr:openrc_retry_init
Open

openrc: retry initialisation if it fails#63
luke-jr wants to merge 1 commit into
vaeth:mainfrom
luke-jr:openrc_retry_init

Conversation

@luke-jr
Copy link
Copy Markdown

@luke-jr luke-jr commented May 14, 2026

The kernel module can take some time to be ready, and 1 second is often not long enough

Probably fixes #62

The kernel module can take some time to be ready, and 1 second is often not long enough
@DevenBL
Copy link
Copy Markdown
Contributor

DevenBL commented May 21, 2026

This seems like it would function much better than my old solution: #46
It's certainly better than just increasing the sleep counter and waiting the full duration.

That the module is loaded is no guarantee that the devices are already unblocked: This can very well be parallel tasks. For the same reason, I do not consider this a bug in the kernel or in modprobe.

If there is a check one can do, than this is to check whether the devices are unblocked. But this is hard to do in shell without actually writing something which would be a bad idea.
#46 (comment)

Would be ideal but i haven't figured out a good way to do it yet either. Do you perhaps know a way to do that @luke-jr ?

However looking at the suddenly increasing complexity of the temporary fix for this problem i feel myself sliding more towards the sentiment that Vaeth might have been correct when he stated:

Perhaps it was wrong to add the option to modprobe in the first place.
#46 (comment)

I wouldn't want to run into this bug a third time twenty years down the line when it takes 11 seconds for zram to be ready since the module loading for zram seems to have gotten slower with newer kernel releases causing this issue to reappear.

@luke-jr
Copy link
Copy Markdown
Author

luke-jr commented May 21, 2026

Even without modprobe support, there's still a potential race.

The possiblity it takes more than 10 seconds is why I made it configurable

@DevenBL
Copy link
Copy Markdown
Contributor

DevenBL commented May 21, 2026

After some more testing

modprobe zram
sleep 10
modprobe zram "num_devices=$num_devices"

Reproduces the issue today as opposed to the 2025 behavior where it didn't. Meaning it no longer matters if the module has already finished loading.

So specifically creating the devices and then trying to use them before they are ready is the issue for: #62

So this pull request is the best fix available until a good way to check and then wait for when the device is ready is found.

Though to be clear i have not actually tested your code yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

zram-init fails to start zramctl: /dev/zram0: failed to reset: Resource busy

2 participants