nginx "accept4() failed (24: Too many open files)"

[harmonypersechino5348]

I am getting the following error with nginx

2022/01/26 03:54:03 [crit] 28222#28222: accept4() failed (24: Too many open files)
2022/01/26 03:54:03 [crit] 28222#28222: accept4() failed (24: Too many open files)
2022/01/26 03:54:04 [crit] 28222#28222: accept4() failed (24: Too many open files)
2022/01/26 03:54:04 [crit] 28222#28222: accept4() failed (24: Too many open files)
2022/01/26 03:54:05 [crit] 28222#28222: accept4() failed (24: Too many open files)

I have came across https://support.cpanel.net/hc/en-us...e-the-number-of-open-files-allowed-for-Nginx- and made the changes however this did not fix the issue.

[[email protected] ~]# grep 'open file' /proc/$(pgrep -u root -f 'nginx: master')/limits

Max open files            99999                99999                files

The file limit is still set low

[[email protected] ~]# ulimit -Hn

4096

[[email protected] ~]# ulimit -Sn

1024

I came across other websites saying that I need to add

/etc/security/limits.conf

nginx       soft    nofile   10000
nginx       hard    nofile  30000

As nginx.conf is currently being run as nobody then I presume I need to change that to

nobody       soft    nofile   10000
nobody       hard    nofile  30000

When trying to verify the changes I get the error

[[email protected] ~]# su - nobody -c 'ulimit -Hn'

This account is currently not available.

How can I verify this is all I need to do?

 

[cPRex]

Hey there! The "nobody" account wasn't available for SSH access because that user typically doesn't login and perform work, so the shell is set to nologin. Here's the output of the /etc/passwd file from an example system showing this:

# grep nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin

Nginx does indeed run as nobody just like Apache. To check a user's limits without shell, you can assign them a temporary session with this command. here's what I see on my personal machine:

# su - nobody -c 'ulimit -Hn' -s '/bin/bash'
4096

Can you try that to see if the values are now set how you expect?

 

[harmonypersechino5348]

Thank you for the reply.

Yes it seems that the values set in /etc/security/limits.conf should resolve this now.

[[email protected] ~]# su - nobody -c 'ulimit -Hn' -s '/bin/bash'
30000

 

[cPRex]

Great - I'm glad you were able to come up with a good solution!