Timeout not working: websites go down

[Edwint]

We have a docker environment with openlitespeed. We have the problem that processes keep running after the timeout time has been reached, websites then go down due to high resource usage.
Php processes that are open for more time then the max idle time our max execution time are crashed at that moment. When visiting the website at that moment there is a timeout message after a while. But the site/docker container is not recovering.
Expected behavior would be a 503 error in browser and recovery in a few minutes, unless the cause of the 503 is not solved. Please note, that after we restart the container everything is working fine again.

We have set max idle time and max execution time + other settings to 90 seconds. So how can we make sure litespeed processes are killed after 90 seconds?

 

[Cold-Egg]

Please check this post to verify the idle time. Let me know if you need more information.
Note, if you haven't implemented cache, please try LSCache to reduce the PHP abd DB load. Verify cache on https://check.lscache.io/

 

[LiteCache]

@Cold-Egg
I tested the noabort and noconntimeout directives with the LSWS and OLS in different scenarios. It works, but not in every case and depends on the PHP processes or child processes. An example of this would be a script that converts images using Imagick. In this case it doesn't work.

 

[Cold-Egg]

Hi @LiteCache
Thanks for sharing.

 

[AndreyPopov]

So how can we make sure litespeed processes are killed after 90 seconds?

I have vice versa problem.

it solved by gracefulRestartTimeout


Graceful Restart Timeout (secs)⇑
Description
During a graceful restart, even after the new server instance is up, the old instance will continue to handle existing requests. This timeout defines how long the previous instance shall wait before exit. Default value is 300 seconds. -1 means wait forever. 0 means no wait and abort immediately.

 

[LiteCache]

@AndreyPopov
If it works with OLS, then that seems fine, but keep in mind that this setting applies to all scripts and is therefore a security risk. But I doubt that this setting works in all cases.

 

[Edwint]

Thanks for the reply's. So the now abort no timeout things is something we do not use. We found out that Wordfence is causing the problems at most websites, we deactivated wordfence and removed the noabort directive from htaccess for those sites. The number of websites that are going down is now a couple in stead of a lot.
The other topic that was mentioned is about setting to have no time out, while we want to have a time out of 90 seconds. In our logs we see the message: LSAPI application, possible dead lock

Normal behavior of a time out setting in OLS / PHP should be the following if i am correct? When 100% cpu and / our memory has been reached, show a 503 error, timeout set to 90 seconds so every running process should be killed after max 90 seconds. Site should be up and running again after not much longer dan 90 seconds. Unless there is something that again causes a high resource usage(in our case thats not the case, after reboot site works fine again)
Are there situations where it can happen that timeout settings are not working? Our should timeout always work?

We have looked at setting php max execution time, the auto fix 503 error is enabled, connection time out setting, External app: LSAPI_MAX_IDLE=90, LSAPI_MAX_PROCESS_TIME=90, Initial Request Timeout, retry time out, max idle time.

 

[LiteCache]

Thanks for the reply's. So the now abort no timeout things is something we do not use. We found out that Wordfence is causing the problems at most websites, we deactivated wordfence and removed the noabort directive from htaccess for those sites.

Wordfence has a misunderstanding of what noabort means. This directive is intended to prevent user abort. Wordfence wants to regulate the timeout, but somehow it doesn't want to get into Wordfence's heads. Also, Wordfence's recommended use of the noabort directive poses a security risk, but Wordfence ignores that too. Ultimately, incorrect use of the noabort directive is at the root of Wordfence's timeout issues.