Problem with reloading nginx config (Let's Encrypt)

Community Support Web
1

Hello,

I encounter an issue with issuing of Let’s Encrypt certificates.
When I try to issue one from the panel, I hit the 400 error dialog box.

Tracking down the error, I see that the file nginx.conf_letsencrypt is correctly created in /home/<user>/conf/web/<domain>.

Nginx is corrrectly reloaded as well.

When using systemctl status nginx, I see

Feb 01 10:31:03 <hostname> systemd[1]: Reloading nginx - high performance web server.
Feb 01 10:31:03 <hostname> systemd[1]: Reloaded nginx - high performance web server.

Despite that, accessing http://<domain>/.well-known/acme-challenge/<LE-id> does not work like if the new nginx config was not loaded.

nginx -t does not show any config error :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Reloading nginx config manually does not work either.
None of the following work :

systemctl reload nginx
nginx -s reload

If I restart nginx with systemctl restart nginx, it works and the http://<domain>/.well-known/acme-challenge/<LE-id> is accessible.

After that, if I resubmit the form in the panel to issue the certificate, it works (the certificate is correctly issued) BUT I need to restart with systemctl restart nginx one more time for the certificate to be presented by nginx.

Obviously somthing is wrong but I cannot find out what is it.

Hestia has been installed in mid February 2021 with no custom or exotic config.
It was working well at the begining but this issue is now present for some time now.

Any idea of what could cause this issue ? This drives me crazy because I do not understand why the config is not correctly reloaded and why a restart is required.

Thanks for your help

1 Like
2

What version are you running ?

3

Hello @eris and thanks for your reply.

apt list hestia
Listing... Done
hestia/buster,now 1.5.7 amd64 [installed]

nginx -v
nginx version: nginx/1.21.6
4

Strange that should be fine. Just tested on my server and I have no issue…

Is it a new domain or an existing one?

5

first of all, thanks for taking the time to provide a lot of information! as you already figured nginx supports reload vs restart, where one is really just reloading the configs and the other actually shuts it down and brings it back up.

as there are not any errors visible I’d suspect some kind of caching being a culprit here, do you use nginx as caching proxy for that domain? at least that would give sense to why a restart works (pruning the cache) …

6

Thank you both for your replies :slight_smile:

@eris I needed to generate an SSL cert from Let’s Encrypt for an existing domain this morning and it went OK to generate the cert from the panel (no error 400) but I still needed to restart nginx for the certificate to be presented by nginx.

This evening, I have created a new domain and I hit the 400 error :wink:

@falzo I checked and the template for proxy is the default one (not caching).

7

Hey there,

I finally take a new shot at this.

Installed nginx-dbg, added the debug directive to the error_log and started it after having stopped nginx.

And I figured it out !

nginx issued an emerg notice that I havent noticed before :

2022/02/21 15:04:38 [emerg] 51772#51772: open() "/var/log/apache2/domains/<redactedforprivacy>.error.log" failed (24: Too many open files)

After digging around, find out how to increase it :

systemctl edit --full nginx.service

and add the following line to the [Service] section:

LimitNOFILE=65536

And now reloading is working as expected, no more need to restart nginx!

I am thrilled, this one was a tough one :blush:

FYI: I have 222 web domains (190 ssl).

Thanks again for your help !

1 Like
8

I just added an issue at Github about this:

Could you check this:

For nginx simply editing nginx.conf and setting worker_rlimit_nofile should change the limitation

worker_rlimit_nofile 4096;

9

Hello,

I confirm that 4096 is sufficient for my use case but it needs to be added to the systemd unit of nginx, otherwise it does not work.

worker_rlimit_nofile directive in nginx config is not enough (can be lower than in the systemd unit but not greater than).

By default on Debian Buster the systemwide limit is set to 1024.

10

Best answer. Worked like a charm for me. Was struggling from last 2 days. You saved me man :smiley:

1 Like