Show the output of this command:
ps -ef | grep -E '[n]ginx'
Hi again, I don’t know if you saw that I had to update my last post because the forum wouldn’t let me send any more replies until after 21 hours because it was a new account. I’m telling you that I haven’t been able to solve the problem. I don’t know if you can think of anything else, but I don’t have much to do.
Hi again, I just found the solution. Searching the forum, I came across this post: Too many open files despite config adjustments - #44 by xeruf This solution was marked there, and it worked for me. I also left only one log file in the nginx templates, trying to create one file instead of thousands, but I think changing the php-fpm.ini file was the winner.
Thank you so much for your help and time yesterday!
Hi,
I’m glad you finally resolved it 
. I never thought it could be related to php-fpm.
Just a quick comment for users who come across this post in the future:
In the post you referenced, the user mentioned modifying the file /usr/local/hestia/php/etc/php-fpm.conf and adding rlimit_files=65535 to the [global] section.
In the current Hestia version, that configuration file is used for the hestia-nginx server, which is independent from the Nginx instance serving web domains. Maybe that worked back then because the Hestia version was 1.6.14 (an old version), and honestly, I’m not sure whether it was also used to serve web domains, maybe it was.
So, if this issue is related to the open files limit for PHP-FPM processes, the file to modify should be /etc/php/x.y/fpm/php-fpm.conf (where x.y is your PHP version). Alternatively, you could adjust this by creating an override.conf file for the systemd service.
Could you please show the output of this command?
IFS=$'\n'; for i in $(ps -ef | grep -E '[p]hp-fpm' | sed -E 's/\s{2,}/ /g'); do pid="$(cut -f 2 -d ' ' <<<"$i")"; process="$(cut -f 8- -d ' ' <<<"$i")"; limit="$(grep 'Max open files' /proc/$pid/limits | sed -E 's/\s{2,}/ /g')"; echo -e "process = $process\npid = $pid\n$limit"; echo; done
Hi, output:
root@hosting-01:~# IFS=$'\n'; for i in $(ps -ef | grep -E '[p]hp-fpm' | sed -E 's/\s{2,}/ /g'); do pid="$(cut -f 2 -d ' ' <<<"$i")"; process="$(cut -f 8- -d ' ' <<<"$i")"; limit="$(grep
'Max open files' /proc/$pid/limits | sed -E 's/\s{2,}/ /g')"; echo -e "process = $process\npid = $pid\n$limit"; echo; done
process = php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
pid = 2970853
Max open files 1024 524288 files
process = php-fpm: master process (/usr/local/hestia/php/etc/php-fpm.conf)
pid = 3002089
Max open files 65535 65535 files
process = php-fpm: pool osornotiffanyfrendo.web.hosting-01.inacap.cl
pid = 3300981
Max open files 1024 524288 files
process = php-fpm: pool palto-martina-barrera.web.hosting-01.inacap.cl
pid = 3300984
Max open files 1024 524288 files
process = php-fpm: pool palto-martina-barrera.web.hosting-01.inacap.cl
pid = 3300986
Max open files 1024 524288 files
process = php-fpm: pool palto-martina-barrera.web.hosting-01.inacap.cl
pid = 3300988
Max open files 1024 524288 files
process = php-fpm: pool palto-guillermo-acuna.web.hosting-01.inacap.cl
pid = 3300989
Max open files 1024 524288 files
process = php-fpm: pool osornoyaelperez.web.hosting-01.inacap.cl
pid = 3300991
Max open files 1024 524288 files
process = php-fpm: pool palto-jreyes.web.hosting-01.inacap.cl
pid = 3300992
Max open files 1024 524288 files
process = php-fpm: pool osorno22132945.web.hosting-01.inacap.cl
pid = 3300994
Max open files 1024 524288 files
root@hosting-01:~#
Ok, your php-fpm services for web domains are still using a limit of 1024.
I would raise the limits for all your php-fpm services:
for i in /etc/php/*; do phpv="$(basename "$i")"; echo "Raising limits to 65535 for php-fpm $phpv"; mkdir -p "/etc/systemd/system/php${phpv}-fpm.service.d"; echo -e "[Service]\nLimitNOFILE=65535" > "/etc/systemd/system/php${phpv}-fpm.service.d/override.conf"; systemctl daemon-reload; systemctl restart php${phpv}-fpm; done
And I would revert the changes you made to the logs to see whether this fixes the issue.
I have already applied this last change and now I am going to revert the logs issue in the templates and perform a rebuild of the websites for all accounts.
root@hosting-01:~# IFS=$'\n'; for i in $(ps -ef | grep -E '[p]hp-fpm' | sed -E 's/\s{2,}/ /g'); do pid="$(cut -f 2 -d ' ' <<<"$i")"; process="$(cut -f 8- -d ' ' <<<"$i")"; limit="$(grep
'Max open files' /proc/$pid/limits | sed -E 's/\s{2,}/ /g')"; echo -e "process = $process\npid = $pid\n$limit"; echo; done
process = php-fpm: master process (/usr/local/hestia/php/etc/php-fpm.conf)
pid = 3002089
Max open files 65535 65535 files
process = php-fpm: master process (/etc/php/8.3/fpm/php-fpm.conf)
pid = 3358510
Max open files 65535 65535 files
process = php-fpm: pool ran19987698.web.hosting-01.inacap.cl
pid = 3358518
Max open files 65535 65535 files
process = php-fpm: pool ran21521645.web.hosting-01.inacap.cl
pid = 3358519
Max open files 65535 65535 files
process = php-fpm: pool ran26530587.web.hosting-01.inacap.cl
pid = 3358521
Max open files 65535 65535 files
process = php-fpm: pool ran22207381.web.hosting-01.inacap.cl
pid = 3358522
Max open files 65535 65535 files
process = php-fpm: pool ran21953635.web.hosting-01.inacap.cl
pid = 3358524
Max open files 65535 65535 files
process = php-fpm: pool palto-jreyes.web.hosting-01.inacap.cl
pid = 3358525
Max open files 65535 65535 files
process = php-fpm: pool ran21052679.web.hosting-01.inacap.cl
pid = 3358526
Max open files 65535 65535 files
process = php-fpm: pool ran21953635.web.hosting-01.inacap.cl
pid = 3358527
Max open files 65535 65535 files
process = php-fpm: pool arica22179805.web.hosting-01.inacap.cl
pid = 3358528
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358529
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358530
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358531
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358532
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358533
Max open files 65535 65535 files
process = php-fpm: pool ran20725094.web.hosting-01.inacap.cl
pid = 3358534
Max open files 65535 65535 files
process = php-fpm: pool ran22426699.web.hosting-01.inacap.cl
pid = 3358535
Max open files 65535 65535 files
process = php-fpm: pool ran21521645.web.hosting-01.inacap.cl
pid = 3358536
Max open files 65535 65535 files
process = php-fpm: pool ran22207381.web.hosting-01.inacap.cl
pid = 3358537
Max open files 65535 65535 files
root@hosting-01:~#
root@hosting-01:~#
1 Like
Apparently it wasn’t the solution, I went back to the original templates where each site has its own individual log and the nginx -t failed again.
root@hosting-01:~# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] open() "/var/log/apache2/domains/diplomado12345678.web.hosting-01.inacap.cl.log" failed (24: Too many open files)
nginx: configuration file /etc/nginx/nginx.conf test failed
root@hosting-01:~#
1 Like
Ok, thanks for testing it.
Now I’m reapplying the change in the caching, default and hosting templates, where I comment out the logs, leave only one, add the new log_format in the nginx.conf and now I’m rebuilding the websites again.
# access_log /var/log/%web_system%/domains/%domain%.log combined;
# access_log /var/log/%web_system%/domains/%domain%.bytes bytes;
access_log /var/log/nginx/access.log host;
This is in /etc/nginx/nginx.conf :
Add this line :
log_format host '$host $remote_addr - $remote_user [$time_local] "$request" $status $bytes_sent "$http_referer" "$http_user_agent"';
1 Like
confirmed, finished rebuilding and now nginx -t works.
rebuild web domain for user: temu-martina-ortiz03
rebuild web domain for user: temu-martin-guzman02
rebuild web domain for user: iquiquematiasmezac
rebuild web domain for user: iquiquemayraplaterom
rebuild web domain for user: iquiquerubensquispech
root@hosting-01:~# systemctl restart nginx
root@hosting-01:~# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
root@hosting-01:~#
Website creation and SSL assignment works perfectly.
1 Like
Hi, it’s me again.
Yesterday I had the same problem again. When nginx performed the configuration integrity test, I got the error “Too many open files.”
I was searching and reading until I came across a 2009 nginx mailing list where some Russians were talking about the same problem in general. In one of those emails, someone indicated that no matter how much the worker_rlimit_nofile was changed, the service still assumed the ulimit of 1024. I checked all the processes and realized that this service:
root 2214 0.0 0.0 22108 2364 ? Ss Oct 16 0:00 nginx: master process /usr/local/hestia/nginx/sbin/hestia-nginx
It kept starting with a ulimit of 1024. I checked the conf file in /usr/local/hestia/nginx/conf/ and it had been modified.
I also found that the user hestiaweb was referencing that process, so I added it to /etc/security/limits.conf, but the nginx -t test kept failing. I continued reading the email thread until they indicated that even if the limit was modified, nginx continued using the ulimit assigned to the root user. They recommended modifying the ulimit for the root user and retrying, so that’s what I did.
I modified the ulimit for root in the /etc/security/limits.conf file, restarted the server to be sure, and believe me, the nginx -t didn’t fail anymore.
I’ve been monitoring it so far, and it still hasn’t failed.
What do you think?
This should be the right approach, afaik:
I did that override but it didn’t solve my problem, also as I told you the nginx service that kept starting with a ulimit of 1024 was this one:
nginx: master process /usr/local/hestia/nginx/sbin/hestia-nginx
and this process was taking the ulimit from the root user and not from the .conf or the override.
did you kill the process and restart nginx or the sever?
also, I am still probably not sure the russian approach is the right one, but if it solved your problem, great. 
Yes, I always restarted the server after each change to be sure, but I personally don’t think it’s the best solution either, so I wanted to continue commenting on the things I’ve tried to find other opinions on the matter.
1 Like