Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I use nginx as a reverse proxy. Whenever I update the config for it using

sudo "cp -r #{nginx_config_path}* /etc/nginx/sites-enabled/"
sudo "kill -s HUP `cat /var/run/`"

I face a brief downtime. How can I avoid that?

share|improve this question
Are those meant to be command line commands? I've never seen anyone wrap an entire sudo command in quotes like that, it may not be necessary. – sh1ftst0rm Apr 12 at 12:59
Just a general comment: I think the standard/recommended practice is create a soft/symbolic link for your site configuration under sites-enabled, not copy it. Not related to your particular issue, but you may want to look into that. – sh1ftst0rm Apr 12 at 13:01
You should not be facing a downtime. kill HUP is the way to do a graceful reload in nginx. – Jonathan Vanasco May 6 at 16:40
up vote 70 down vote accepted

Run service nginx reload or /etc/init.d/nginx reload

It will do a hot reload of the configuration without downtime. If you have pending requests, then there will be lingering nginx processes that will handle those connections before it dies, so it's an extremely graceful way to reload configs.

Sometimes you may want to prepend with sudo

share|improve this answer
Both of those should do exactly what the question states: send SIGHUP to the nginx master process. There should not be a difference. – Gnarfoz Jul 27 '12 at 12:36
When I issue the command on CentOS it keeps saying "Usage /etc/init.d/nginx (start..stop...restart..reload)" .. and that's exactly how I used it. Within the file /init.d/nginx I found kill -HUP cat $PIDFILE || echo -n " can't reload" – mashup Apr 13 '15 at 18:21

Run /usr/sbin/nginx -s reload

See for more command line options.

share|improve this answer

Usually, reloading configuration file of a service should not affect the running service. However, this depends on how the SIGHUP signal is processed.

If a specific service is experiencing a downtime during reload, this can be circumvented by running the same service on multiple servers preferably using a load balancer. In this case, you can take out one server at a time and reload/restart it. Then, it can be re-added after confirming it is OK.

share|improve this answer
While this does not directly answer the question, this is definitely a best-practice scenario that the OP would be smart to follow for avoiding downtime in general. – Andrew M. Apr 11 '12 at 17:29
Details on how nginx handles different signals: – Gnarfoz Jul 27 '12 at 12:37

No, you are incorrect, you aren't supposed to be facing any downtime with the procedure you describe. (Nginx can do not only configuration reload on the fly without any downtime, but even the upgrade of the executable on the fly, still without any downtime.)

As per, sending the HUP signal to nginx makes sure that it performs a graceful restart, and, if the configuration files are incorrect, the whole procedure is abandoned, and you're left with the nginx as before sending the HUP signal. At no point should any downtime be possible.

In order for nginx to re-read the configuration file, a HUP signal should be sent to the master process. The master process first checks the syntax validity, then tries to apply new configuration, that is, to open log files and new listen sockets. If this fails, it rolls back changes and continues to work with old configuration.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.