For the past two years I have suffered from a seemingly random issue where my Unraid server logs will fill up endlessly with errors similar to the following: 

Quote

Mar 25 00:45:47 unraid nginx: 2024/03/25 00:45:47 [alert] 3161#3161: worker process 4945 exited on signal 6
Mar 25 00:45:49 unraid nginx: 2024/03/25 00:45:49 [alert] 3161#3161: worker process 4964 exited on signal 6
Mar 25 00:45:51 unraid nginx: 2024/03/25 00:45:51 [alert] 3161#3161: worker process 4985 exited on signal 6
Mar 25 00:45:53 unraid nginx: 2024/03/25 00:45:53 [alert] 3161#3161: worker process 5003 exited on signal 6
Mar 25 00:45:55 unraid nginx: 2025/03/25 00:45:55 [alert] 3161#3161: worker process 5023 exited on signal 6

This eventually leads to the WebUI becoming slow, then unresponsive. Unless I caught it in time, which was never a given since this could happen at any time, it would lock everything up to the point I could not open the terminal or even click the shut down button. This led to a lot more hard restarts of my server than I would like. 

 

One thing I noted is that the issue would come and go but, for the majority of  my time experiencing it, would happen after between 2-3 weeks since the last episode. However back in November 2024, it increased to the point that my server was rebooting and would freeze again within hours. This was, of course, unbearable and forced me to try everything until I found a solution. 

 

In my search for a solution I came upon many possibilities but never found a single location for people to say what worked and what didn't or to list solutions. That is what this post aims to be. My hope would be for others to comment and say what worked and what didn't for them as well. 

Here is a list of solutions which I tried based on the myriad of comments on other forum/Reddit posts on this seemingly common issue.   

Solutions: 

Stale Browser:
For many this issue is caused by a persistent bug within Unraid which triggers these exact same NGINX errors if a browser window to the Unraid GUI is left open and untouched for too long. Despite having fixed the main issue on my server, this bug is still present. 

 

**Please ensure you do not have any stale Unraid GUI browser tabs open on any of your devices.** 

 

This will likely be the solution for most of you.

If this is not your issue, here is a list of other possible solutions, including what ultimately worked for me. I have done my best to credit the original commenters. 

 

If this is not a consistent issue for you and your server has not yet become completely unresponsive: 

Manually reboot NGINX via terminal: 

`/etc/rc.d/rc.nginx restart`

 
This can also be triggered automatically via the User Scripts plugin. For a time this resolved my issues, until the error spam became too frequent. 
Credit:
https://xavier.cc/servers/unraid/unraid-nchan-out-of-shared-memory-while-allocating

 

Or, manually restart NGINX via SSH:

#!/usr/bin/env bash

pkill -9 nginx
pkillexitstatus=$?

if [ $pkillexitstatus -eq 0 ]; then
    echo "pkill exited normally with nginx killed"
elif [ $pkillexitstatus -eq 1]; then
    echo "could not find nginx process to kill"
elif [ $pkillexitstatus -eq 2]; then
    echo "syntax error in trying to kill nginx using \'pkill -9 nginx\'"
elif [ $pkillexitstatus -eq 3]; then
    echo "fatal error using \'pkill -9 nginx\'"
else
    echo UNEXPECTED
fi

/etc/rc.d/rc.nginx start

nginxstatus=$?

if [ $nginxstatus -eq 0 ]; then
    echo "nginx restarted normally with exit code " $nginxstatus
else
    echo "nginx restart returned an abnormal exit code: " $nginxstatus
fi

Credit & Context:

 

If the above solutions fail to help, consider the possibility that the issue lies with a docker container or a plugin. Consider booting into safe mode for a time to see if the issue goes away when containers, VMs, and plugins are all disabled. This can be difficult if you frequently use your server for things so you may consider, if the errors are occurring frequently enough, going through and shutting down as many containers, VMs, and plugins as possible. 

 

One user reported that removing Unraid Connect resolved their issue:

Remove Unraid Connect:

 

 

Note that this will stop the automatic flash backup of your USB drive to Unraid.

Increase nchan_max_reserved_memory: 

This solution has apparently worked for some people as well. It didn't seem to do anything for me but if you're here it's worth a shot.

Open terminal and open the nginx config file located at: 

/etc/nginx/nginx.config

You can use the "nano" command to open the file directly in the terminal. Edit your NGINX config file to include:

http {
    nchan_max_reserved_memory 128M;  # Adjust the value based on your available system memory
}

Credit:

 

What finally worked for me:

This ultimately fixed the problem for my server, with the exception of the stale browser tab issue which is apparently a chronic Unraid problem. This solution isn't even for Unraid but it solved my issue completely. 

Open terminal and open the nginx config file located at: 

/etc/nginx/nginx.config

Add the following line within the `http` block:

http {  
    …
    ssl_session_cache    shared:SSL:10m;
    …
}

 

Restart NGINX.

 

Credit: https://futurestud.io/tutorials/nginx-solve-reponse-status-0-worker-process-exited

(May this man have the happiest of lives)

 

Discouraged:
Increasing log file size. This is an option but it likely will not solve anything. It will only take a bit longer for the log file to fill up and then you will be back to square one again.

 

Conclusion

There are likely more possible solutions which I have either missed or which people have not yet figured out. If you encounter any, please post them below! I hope at least one of these solutions has resolved your issue! 

19 minutes ago, UnraidCitadel said:

Mar 25 00:45:47 unraid nginx: 2024/03/25 00:45:47 [alert] 3161#3161: worker process 4945 exited on signal 6
Mar 25 00:45:49 unraid nginx: 2024/03/25 00:45:49 [alert] 3161#3161: worker process 4964 exited on signal 6
Mar 25 00:45:51 unraid nginx: 2024/03/25 00:45:51 [alert] 3161#3161: worker process 4985 exited on signal 6

 

Thanks for posting your findings, just to confirm, you only got those errors, or sometimes also similar to these?

Feb  4 18:31:44 Tower1 php-fpm[8654]: [WARNING] [pool www] child 2021772 exited on signal 9 (SIGKILL) after 43.960995 seconds from start
Feb  4 18:31:46 Tower1 php-fpm[8654]: [WARNING] [pool www] child 2024934 exited on signal 9 (SIGKILL) after 17.995217 seconds from start
Feb  4 18:32:27 Tower1 php-fpm[8654]: [WARNING] [pool www] child 2028053 exited on signal 9 (SIGKILL) after 25.084388 seconds from start
Feb  4 18:32:33 Tower1 php-fpm[8654]: [WARNING] [pool www] child 2028054 exited on signal 9 (SIGKILL) after 31.366233 seconds from start
Feb  4 18:33:55 Tower1 php-fpm[8654]: [WARNING] [pool www] child 2038397 exited on signal 9 (SIGKILL) after 14.197867 seconds from start

 

Hmm, looking at nginx.conf, that option is already there:

 

11 minutes ago, JorgeB said:

Hmm, looking at nginx.conf, that option is already there:

 

same

 

root@Docker:/etc/nginx# cat nginx.conf 
# Unraid

user  root;
worker_processes  1;

pid /var/run/nginx.pid;


events {
    worker_connections  1024;

    # Accept as many connections as possible after getting a notification about a new connection
    multi_accept on;

    # Which polling method we should use for multiplexing clients on to threads. If you’re using Linux 2.6+, you should use epoll.
    use epoll;
}


# Default error log file
# (this is only used when you don't override error_log on a server{} level)
#
# limetech - here we write log messages to the raw socket where rsyslogd is listening.
# Another way to do it is with this line:
#  error_log syslog:server=localhost,nohostname;
# and then also uncomment these two lines in /etc/rsyslog.conf:
#  #$ModLoad imudp  # provides UDP syslog reception
#  #$UDPServerRun 514 # start a UDP syslog server at standard port 514
# Not sure which method is better...
#
error_log syslog:server=unix:/dev/log,nohostname;


http {

    ##
    # Basic Settings
    ##

    # Hide nginx version information.
    server_tokens off;

    # Define the MIME types for files.
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # How long to allow each connection to stay idle; longer values are better
    # for each individual client, particularly for SSL, but means that worker
    # connections are tied up longer. (Default: 65)
    keepalive_timeout 20;

    # Speed up file transfers by using sendfile() to copy directly
    # between descriptors rather than using read()/write().
    sendfile        on;

    # Tell Nginx not to send out partial frames; this increases throughput
    # since TCP frames are filled up before being sent out. (adds TCP_CORK)
    tcp_nopush      on;

    # Tell Nginx to enable the Nagle buffering algorithm for TCP packets, which
    # collates several smaller packets together into one larger packet, thus saving
    # bandwidth at the cost of a nearly imperceptible increase to latency. (removes TCP_NODELAY)
    tcp_nodelay     on;

    # Turn off buffering for proxy requests to be able to support 'flush' during progress updates
    proxy_buffering off;

    client_header_timeout 20;
    client_body_timeout 20;
    client_body_buffer_size 32k;
    send_timeout 20;
    fastcgi_read_timeout 640s;
    fastcgi_keep_conn on;

    types_hash_max_size 2048;
    client_max_body_size 20m;

    server_names_hash_bucket_size 128;
    server_name_in_redirect off;
    port_in_redirect off;


    ##
    # Logging Settings
    ##

    # Format to use in log files
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    # Default log file
    # (this is only used when you don't override access_log on a server{} level)
    # access_log /var/log/nginx/access.log;
    access_log  off;


    ##
    # Gzip Settings
    ##

    # Disable Gzip compression to support 'flush' progress updates
    gzip off;


    ##
    # SSL Settings
    ##

    # Protect against the BEAST attack by preferring RC4-SHA when using SSLv3 and TLS protocols.
    # Note that TLSv1.1 and TLSv1.2 are immune to the beast attack but only work with OpenSSL v1.0.1 and higher and has limited client support.
    # SSLv3 removed due to POODLE exploit and CRIME attack
    # 3DES removed due to SWEET32 attach
    ssl_protocols              TLSv1.3 TLSv1.2;
    ssl_ciphers                "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!3DES";
    ssl_ecdh_curve             secp384r1;
    ssl_prefer_server_ciphers  on;
    ssl_dhparam                /etc/nginx/dhparam.pem;

    # Optimize SSL by caching session parameters for 10 minutes. This cuts down on the number of expensive SSL handshakes.
    # The handshake is the most CPU-intensive operation, and by default it is re-negotiated on every new/parallel connection.
    # By enabling a cache (of type "shared between all Nginx workers"), we tell the client to re-use the already negotiated state.
    # Further optimization can be achieved by raising keepalive_timeout, but that shouldn't be done unless you serve primarily HTTPS.
    ssl_session_cache    shared:SSL:10m;  # a 1mb cache can hold about 4000 sessions
    ssl_session_timeout  10m;
    ssl_session_tickets  off;

    map $http_upgrade $connection_upgrade {
        default Upgrade;
        '' close;
    }

    ##
    # Authentication Settings
    ##

    satisfy any;
    allow 127.0.0.1;
    allow ::1;
    allow unix:;
    deny  all;
    auth_request /auth-request.php;

    # limit the amount of failed auth requests per IP address
    limit_req_zone $binary_remote_addr zone=authlimit:1m rate=30r/m;

    ##
    # Security Settings
    ##
    add_header X-Content-Type-Options 'nosniff';
    add_header Referrer-Policy 'same-origin';

    ##
    # set root directory for requests
    ##
    #
    root /usr/local/emhttp;

    include /etc/nginx/conf.d/servers.conf;
}

unraid v7 stable has the option set...

Quote

Add the following line within the `http` block:

http {       …     ssl_session_cache    shared:SSL:10m;     … }

However the additional server.conf does not:
 

root@Docker:/etc/nginx/conf.d# cat servers.conf

the config found here:

was in early beta...

my only additional test is when you connect to the unraid web ui and leave it open for x time. did you go to http or https?

I'm still having this issue on 7.0.1. Reboot is the only way to solve

 

 

 

i need to know some questions....

clearly there is soemthignon teh network, service etc hiting the unraid web server Alot for this to occur... What is runing ? netowrk scan ? automation system ? etc taht would also call and talk back to the web page?

Is this going to http or https... I would need to know to give / fix nginx config to add aditional to close the wegbpage and session...

Mem test! As very few hit this And I trest unraid and alot of sytmes on a lot of hardware I doubt this to be a software bug.. So i'm left with faulty ram and/or OOM or a edited nginx config...

as It looks like your Nginx instance running on Unraid is experiencing frequent worker process crashes due to signal 6 (SIGABRT). This typically happens due to issues like memory corruption, misconfigurations, or software bugs...

 

Check Logs for More Details

Nginx logs critical information in:

Access Logs: /var/log/nginx/access.log

Error Logs: /var/log/nginx/error.log

 

I would need nginx only logs.... and diag 
 

 

esential setup a syslog server ....


AS a workaround...

Monitor Nginx with a Script....

Use a simple script to monitor Nginx and restart it when it crashes:

Create a monitoring script:

#!/bin/bash

LOG_FILE="/var/log/nginx_monitor.log"

while true; do
    if ! pgrep nginx > /dev/null; then
        echo "$(date) - Nginx crashed! Restarting..." | tee -a "$LOG_FILE"
        /etc/rc.d/rc.nginx restart
    fi
    sleep 10
done

cron it to run on every hour....


Did you install or change a theme? are you entering the flashdirve and changing the config files?
what services if any are you running...

As I have yet to see nginx on unraid do this and I can't reproduce...

I occasionally see the same issue on my Unraid box. I've not had the UI become unresponsive yet, and it only happens infrequently, but I do sometimes leave a tab open on the dashboard. Fresh install of 7.0.0 recently updated to 7.0.1. There is no load on the server, and nothing is hitting it when this happens except the one tab open to the dashboard.

 

I was just affected by the same issue. Logs show the exact same symptoms. /var/logs was filled 100% too.
Restarting solved, but I expect to come across this issue again, as I sometimes forget Unraid tab open somewhere..

the only thing i can think to add is a keepalive to the nginx so if a tab is left open lets say 1 hour. the keep alive time out will expire and the page will disconect and contune rendering data.

I asume its left on the dashbaoord or some other intensive docekr or webpage with unraid that is calling data. AS I can't reproduce this...

so... IF
 

Experiencing emhttp or nginx errors in Unraid when leaving dashboard tabs open is a known issue. This often occurs due to persistent browser connections that can lead to resource exhaustion or unexpected server behavior. To mitigate this, you can configure NGINX to close idle connections after a specified period, such as one hour.

Implementing a One-Hour Timeout for Idle Connections in NGINX:

Access the NGINX Configuration File:

Locate your NGINX configuration file, typically found at /etc/nginx/nginx.conf or within the /etc/nginx/conf.d/ directory.

Set the keepalive_timeout Directive:

The keepalive_timeout directive determines how long an idle client connection remains open. To set this to one hour (3600 seconds), add or modify the following line within the http or server block:

keepalive_timeout 3600s;

-This configuration ensures that idle connections are closed after one hour, helping to prevent issues related to long-lived connections.

 

We can alos check and adjust:

Adjust the client_body_timeout and client_header_timeout Directives:

These directives define the time the server will wait for the client body and header, respectively. Set them to appropriate values to ensure timely handling of client requests:

 

client_body_timeout 60s;
client_header_timeout 60s;

-Setting these to 60 seconds means the server will wait up to one minute for the client to send the body or header of the request.

 

outside of that would realy need a catlast to test to reporduce this...

I sitll haven't gotten if its a http / https page that its left on as both would have other nginx / fixes assocated..

 

here is a untested script... reused the nchan from the other fourm...
 

something to add this to unraid at start... user script plugin at first start of the array.
 

#!/bin/bash
# Unraid User Script to modify nginx.conf and restart NGINX

# Define file paths
NGINX_CONF="/etc/nginx/nginx.conf"
BACKUP_CONF="/etc/nginx/nginx.conf.bak"

# Backup the existing nginx.conf
if [ -f "$NGINX_CONF" ]; then
    cp "$NGINX_CONF" "$BACKUP_CONF"
    echo "Backup created at $BACKUP_CONF"
else
    echo "Error: $NGINX_CONF not found! Exiting."
    exit 1
fi

# Add or modify the keepalive_timeout, client_body_timeout, and client_header_timeout directives
sed -i '/http {/a \
    keepalive_timeout 3600s;\
    client_body_timeout 60s;\
    client_header_timeout 60s;' "$NGINX_CONF"

if [ $? -eq 0 ]; then
    echo "NGINX configuration updated successfully."
else
    echo "Error: Failed to update NGINX configuration."
    exit 1
fi

# Restart NGINX
/etc/rc.d/rc.nginx restart

if [ $? -eq 0 ]; then
    echo "NGINX restarted successfully."
else
    echo "Error: Failed to restart NGINX. Check configuration."
    exit 1
fi

exit 0

 

Explanation of the Script:

Backup: Creates a backup of the current nginx.conf file.

Modify Configuration: Inserts the keepalive_timeout, client_body_timeout, and client_header_timeout directives within the http block of the nginx.conf file.

Restart NGINX: Restarts the NGINX service to apply the new settings.

3. Schedule the Script to Run at Boot:

In the User Scripts interface, set the script to run at "At First Array Start Only". This ensures the script executes during the system's startup process.Reddit

4. Test the Script:

Before relying on the script at boot, run it manually by clicking "Run Script" in the User Scripts interface.

Check the output for any errors and verify that NGINX restarts successfully.

5. Reboot to Confirm:

Restart your Unraid server to ensure the script runs as expected during the boot process.

After rebooting, verify that the NGINX configuration contains the updated timeout settings.