CODEWITHSUNDEEP
node.jswordpressnginxubuntu-16.04
Kirill Miniaev
Kirill Miniaev

Reputation: 303

NGINX randomly stops working, required manual restart

I have an issue I am not sure how to troubleshoot. My setup:

The Issue:

Every few days it seems like NGINX stops working. I can tell because I am unable to access the Wordpress site until I run sudo service nginx restart. It does not seem to be a PHP issue, since if I restart PHP the Wordpress site DOES NOT go back online until the NGINX restart. The server logs in /var/log/nginx don't seem to give any insight, and I am unsure how to troubleshoot the issue.

Any ideas on where to start? Any monitoring I can set up (apart form just a basic "site down") that might provide insight? Maybe there is some setting that I can toggle in NGINX that handles overuse (if that is the issue)?

Upvotes: 6

Views: 5753

Answers (2)

oOnez
oOnez

Reputation: 897

I encountered a similar issue when using nginx with certbot. I am hosting under Ubuntu 16.04 LTS and certbot is quite outdated (0.10.2).

As described here this version of certbot suffers an issue when emiting a certificate. The standard commands don't works, specific commands must be used.

Certbot comes with an auto updater that will renew certificates automatically. This updater fails to use the workaround and also fails to start the nginx service after operations.

What I did is to disable this service. There is a file at /etc/systemd/system/timers.target.wants/certbot.timer. Edit this file and comment the lines that enable the timer. 

[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
Persistent=true

#[Install]
#WantedBy=timers.target

Now you will have to renew the certificates manually.

Upvotes: 7

cnst
cnst

Reputation: 27218

How do you specify the upstream servers for nginx?

You should note that normally, http://nginx.org/r/proxy_pass caches the resolution of the domain names at startup time, unless you're using variables within proxy_pass together with the http://nginx.org/r/resolver directive.

What this means is that the resolution of the name may become stale and incorrect, resulting in the pages no longer loading.

The solution would be to use variables within proxy_pass, as well as specifying a resolver to use for ongoing resolutions.

Otherwise, the error log should still be useful to provide information on what's the cause of the downtime; make sure you're looking at the global http://nginx.org/r/error_log, not the error_log of the individual servers, which often won't have anything interesting in case of a serious issue affecting nginx as a whole.

Upvotes: 0

Related Questions