RFE: expose sqliteOptionBusyTimeout as config or env variable.

[dougsland]

Feature request description

A clear and concise description of what the feature request is about.

We are executing several stress tests against podman with engine-stressor and depending of the tuning/settings in the system with stress-ng tool we start seeing the famous "save transaction: database is locked"

Would be nice to have a way to increase/decreate sqliteOptionBusyTimeout to see if that affects the system without the need to recompile the libpod. On top that, it worth mentioning that changing that value should not corrupt the database itself.

I could offer help to implement such mechanism but better listen the team how they would like to drive this request.

Reference:

podman/libpod/sqlite_state.go

Line 45 in b3afb8f

sqliteOptionBusyTimeout = "&_busy_timeout=100000"

Thanks
Douglas

Suggest potential solution

A clear and concise description of what you want to happen.

Add such option into config?
Env variable?

Have you considered any alternatives?

A clear and concise description of any alternative solutions or features you've considered.

Rebuild manually podman/libpod

Additional context

Add any other context or screenshots about the feature request here.

Doing stress test against podman to a automobile certification which uses podman as container engine.

[Luap99]

Adding a env variable to experiment would be fine for me but this shouldn't be something that would be documented/recommend for normal users I think.

Overall the question is what would be your goal? Just increasing the timeout? If so by how much? At some point we must consider that podman is practically unusable if the db is so slow.

[Luap99]

cc @mheon

[dougsland]

Adding a env variable to experiment would be fine for me but this shouldn't be something that would be documented/recommend for normal users I think.

Overall the question is what would be your goal? Just increasing the timeout? If so by how much? At some point
we must consider that podman is practically unusable if the db is so slow.

It's an experimental thing, adjusting the timeout (depending of the load of the stress) in the end I would like to proof that increasing the timeout won't help as the stress will keep coming. However, in either way, rebuild libpod doesn't seem very welcome to me, of course, if it's something like 'safety matter' to prevent users to change it, fine for me we can close this one.

[Luap99]

I am fine to have a env var to experiment, by all means the current 100s is arbitrary. If you can test different timings and find something that works better in practise then this is valuable knowledge and we could consider chaining the default.

But well that is my opinion we still should have consent from other maintainers.

[baude]

Im also ok with an environment variable initially as well.

[mheon]

I have no objections. I wouldn't want to document this as part of our public API (I think most users will get into more trouble than good trying to play with this) but an environment variable for testing is perfectly fine.