NGINX Troubleshoot Free Sample Questions

The 'nginx -s quit' command sends a QUIT signal to the NGINX master process, which initiates a graceful shutdown. The master process instructs the worker processes to stop accepting new connections, finish servicing current requests, and then exit. The 'nginx -s stop' command sends a TERM signal, which causes a fast (immediate) shutdown, dropping active connections. 'nginx -s reload' is for configuration changes, not shutting down.

A reload ('nginx -s reload' or sending a HUP signal) is the correct procedure for applying configuration changes without downtime. The master process verifies the syntax, applies the new config, starts new worker processes, and sends a message to the old worker processes requesting them to shut down gracefully (draining existing connections). A full restart will drop active connections.

The 'nginx -T' (capital T) command tests the configuration file and dumps the entire parsed configuration to standard output. This is extremely useful when troubleshooting complex setups with multiple 'include' directives, as it shows exactly what NGINX sees after merging all files. 'nginx -t' only tests the syntax and reports success or failure without dumping the config.

Sending a QUIT signal to the NGINX master process initiates a graceful shutdown (equivalent to 'nginx -s quit').

Sending a HUP signal to the NGINX master process triggers a configuration reload (equivalent to 'nginx -s reload').

False. A reload is specifically designed to be graceful. The master process starts new worker processes with the new configuration and sends a message to the old worker processes to shut down gracefully. The old workers stop accepting new connections but will continue to service their existing in-flight connections until they are completed.

If the master process is killed ungracefully (SIGKILL/-9), the worker processes become orphaned but continue to run and serve traffic. A new master process cannot adopt them, and 'nginx -s' commands will fail because the PID file points to a dead master. The correct recovery is to manually send SIGQUIT to the worker processes (allowing them to finish in-flight requests gracefully) and then start the NGINX service normally.