No request delivery notification has been received from LSAPI process group

No request delivery notification has been received from LSAPI application, possible dead

solved follow all mentioned below

increase PHP memory 

/usr/local/lsws/lsphp80/etc/php/8.0/litespeed

memory_limit = 5028M

or same can be done from cyber panel also increase in all php versions if installed multiple

 2022-06-30 08:50:46.012597 [NOTICE] [65167] [172.69.71.154:51630:HTTP2-1#ytmp3.su] No request delivery notification has been received from LSAPI application, possible dead lock.

I have made the following changes to fix this issue.

Modified PHP settings in Litespeed web console.

Max Connections: 50Instances : 50
Environment: PHP_LSAPI_CHILDREN=50
             PHP_LSAPI_MAX_REQUESTS=500
             LSAPI_PGRP_MAX_IDLE=10
             LSAPI_AVOID_FORK=1
Initial Request Timeout (secs): 60
Connection Keep-Alive Timeout: 60
Memory Soft Limit (bytes): 4024M
Memory Hard Limit (bytes): 4024M
Process Soft Limit: 2400
Process Hard Limit: 2500

Most FastCGI/LSAPI applications can only process one request per process instance and for those types of applications, instances should be set to match the value of "Max Connections".

reboot server once done this is important as PHP run in deattached mode means reseting lsws and openlitespeed will not relect the settings

What is PHP Detached Mode?

PHP Detached Mode is a big feature available in LSWS 5.3 and later. OpenLiteSpeed supports PHP detached mode starting from 1.5.6.

In previous versions (LSWS 5.2.x and below), all PHP processes were attached to LiteSpeed Web Server processes. As such, when LiteSpeed Web Server restarted, so would the PHP processes. In PHP Detached Mode, the PHP processes will continue running independently, even when LiteSpeed Web Server restarts.

When you run in PHP ProcessGroup Mode, PHP process groups are still started by the litespeed process. When the first request for a specific PHP process group comes in, if PHP is not running it, it will be started by LiteSpeed. pstree will show that PHP process is child of the litespeed process. That's normal. What's new is that, as of 5.3, once the litespeed process exits, the PHP process won't quit. It will become independent.

Restart Detached PHP Processes

In the past, if there were any php.ini changes, you would probably want to restart LSWS to apply the changes(since LSWS will restart PHP processes).

As of LSWS 5.3, PHP runs in detached mode and won't be restarted during LSWS restart. If you want to make php.ini changes effective immediately, there are a few ways to restart PHP processes.

For a User

To restart detached PHP processes for the account (vhost) level, you can touch a .lsphp_restart.txt file under the user's home directory, for example /home/USER1/ on a cPanel/WHM server:

touch /home/USER1/.lsphp_restart.txt

Once .lsphp_restart.txt is created, the user's PHP will be restarted when next request comes in. The file .lsphp_restart.txt won't be removed. LSWS will check the timestamp of the file to decide if the user's detached PHP needs to be restarted or not. You can manually remove it if you want to but it's not necessary. Every time you want to restart that user's detached PHP, you can just touch the file again, whether it already exists or not, in order to refresh the timestamp.

To maintain CloudLinux mod_lsapi CRIU feature compatibility, the server will restart PHP if it finds a mod_lsapi_reset_me file as well.

touch <user_home_dir>/mod_lsapi_reset_me

The user may also restart detached PHP processes from the Advanced page of the LiteSpeed Web Cache Manager cPanel plugin, accessible from within the cPanel dashboard.

For the Server

To restart detached PHP processes for the server level, you can touch a .lsphp_restart.txt file under the <lsws_server_root>/admin/tmp/ directory. Usually, that is /usr/local/lsws/admin/tmp/.

touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt

This can also be accomplished from the 'Actions' page of the LiteSpeed WebAdmin Console or by using the 'Restart Detached PHP Processes' button in the LiteSpeed cPanel/WHM plugin.

All running detached PHP processes will be restarted, but not immediately. Instead, they will restart as soon as the server needs to use that PHP handler.

Stop All Immediately

To stop all lsphp processes immediately, you can manually kill them from the command line:

killall lsphp

Also, In server configuration set CPU Affinity to 1. And disable Gzip compression if you are facing any database memory full errors.
An alternate fix for database memory full error is to increase your temporary file storage size.

first, check which one is used by you.

virtual host or server level

then adjust according to that

For server level

also you can check if any specific script is causing the dead lock

top -c | grep ss

ssyoutube is the user for which dead lock was happening

Server Configuration > External App

After a day of running php inside of GDB, I could see there where far fewer crashes (say 5) then the number of these errors I have received.

I reapplied LSAPI_ACCEPT_NOTIFY=0 on the lsapi processes and restarted - it seemed to go away.

I also notice these errors when restarting lsws.

check date for these fodlers

drwxr-xr-x  3 lscpd     lscpd        4096 Jun 30 16:35 lscpd/

drwxr-xr-x  3 nobody    nogroup     12288 Jun 30 16:52 lshttpd/

inside /tmp

that should be recent

but when going to the /tmp/lshttpd folder the last modified date wasn’t changed, indicating that for some reason (permissions) LiteSpeed failed to recreate them. For a quick fix, instead of changing the permissions, simply stop litespeed web service, rename the directory and restart litespeed. That way Litespeed recreates the entire lshttpd folder in /tmp.

service litespeed stop
mv /tmp/lshttpd/ /tmp/lshttpd1/
service litespeed start

Advice to those who will have strange lags or errors like this on CyberPanel:
No request delivery notification has been received from LSAPI application, possible dead lock.
 
Go to Server Configuration > App Server and change the Max Connections setting from 10 to 150 for example. Because of this parameter, sites on different engines worked strangely for me, and after the change everything became fine.






I used to be hosted with WP Engine and their Mu-Plugin leftover from being hosted with them was causing some sort of conflict. Deleting those plugins fixed the problem!!!