Shulou(Shulou.com)06/02 Report--

I. background

In the process of server development, it is inevitable to restart the service to load new code or configuration. If the service is guaranteed to be uninterrupted during server restart, the impact of restart on business can be reduced to 0. Recently, I conducted a survey on the smooth restart of nginx. I found it very interesting and recorded it for students who are interested to consult.

Restart the process

Restart means the replacement of new and old, and there is bound to be the coexistence of new and old server in the process of handing over tasks. therefore, the process of restart is roughly as follows: start the new server and the old server coexist, and the two deal with the request together and provide services to the old server after dealing with all the requests. The main problem is how to ensure that the new and old server can coexist, if the server ports before and after reboot are the same. How to ensure that both can listen to the same port.

Third, nginx implementation

In order to verify the smooth restart of nginx, the author first tries to open a new server instance when nginx is started. The result is as follows:

Obviously, reopening the server instance won't work because the old and new server use the same port 80, and the bind system call will make an error when you don't start the socket reuseport option to reuse the port. By default, nginx bind retries 5 times and exits directly after failure. Nginx needs to listen to IPV4 address 0.0.0.0 and IPV6 address [:], so 10 emerg logs are printed in the figure.

Then try the smooth restart command, with a total of two commands:

Kill-USR2 `cat / var/run/ nginx.pid`kill-QUIT `cat / var/run/ nginx.pid.oldbin`

The first command is to send a signal USR2 to the old master process, whose pid is stored in the / var/run/nginx.pid file, where the nginx.pid file path is configured by nginx.conf.

The second command sends a signal QUIT to the old master process, whose pid is stored in the / var/run/nginx.pid.oldbin file, and then the old master process exits.

So the question is, why does the pid of the old master process exist in two pid files? In fact, after sending the signal USR2 to the old master process, the old master process renamed the pid so that the original nginx.pid file rename became nginx.pid.oldbin. In this way, the new master implementation can use the file name nginx.pid.

Execute the first command first, and the result is shown in the figure:

Yes, the new and old master and worker processes coexist. Let's take a second command, and the result is as follows:

As you can see, the old master process 8527 and its worker process all quit, leaving only the new master process 12740.

I can't help but wonder why it doesn't work to open a new instance manually, which can be achieved by using a signal restart. First take a look at the nginx log file:

In addition to the previous error log, there is an extra notice, which means it inherits sockets, with an FD value of 6 and 7. As the log flips through the nginx source code, navigate to the nginx.c/ngx_exec_new_binary function

Ngx_pid_tngx_exec_new_binary (ngx_cycle_t * cycle, char * const * argv) {. Ctx.path = argv [0]; ctx.name = "new binary process"; ctx.argv = argv; n = 2; env = ngx_set_environment (cycle, & n); Var = ngx_alloc (sizeof (NGINX_VAR) + cycle- > listening.nelts * (NGX_INT32_LEN + 1) + 2, cycle- > log); P = ngx_cpymem (var, NGINX_VAR "=", sizeof (NGINX_VAR)); ls = cycle- > listening.elts; for (I = 0; I

Listening.nelts; iTunes +) {p = ngx_sprintf (p, "% ud;", LS [I] .fd);} * p ='\ 0mm; env [nasty +] = var;... Env [n] = NULL;... Ctx.envp = (char * const *) env; ccf = (ngx_core_conf_t *) ngx_get_conf (cycle- > conf_ctx, ngx_core_module); if (ngx_rename_file (ccf- > pid.data, ccf- > oldpid.data) = = NGX_FILE_ERROR) {. Return NGX_INVALID_PID;} pid = ngx_execute (cycle, & ctx); if (pid = = NGX_INVALID_PID) {if (ngx_rename_file (ccf- > oldpid.data, ccf- > pid.data) = = NGX_FILE_ERROR) {...}}. Return pid;}

The flow of the function is

Copy all fd that the old master process listens to to the env environment variable NGINX_VAR of the new master process. Rename renames the pid file ngx_execute function to the execve child process, and the execve executes the command line to start the new server. In the server startup process, the parsing of the environment variable NGINX_VAR is involved. The ngx_connection.c/ngx_add_inherited_sockets code is: static ngx_int_tngx_add_inherited_sockets (ngx_cycle_t * cycle) {. Inherited = (u_char *) getenv (NGINX_VAR); if (inherited = = NULL) {return NGX_OK;} if (ngx_array_init (& cycle- > listening, cycle- > pool, 10, sizeof (ngx_listening_t))! = NGX_OK) {return NGX_ERROR;} for (p = inherited, v = p; * p; pause +) {if (* p =':'| * p = ='| * p = ='| ) {s = ngx_atoi (v, p-v); V = p + 1; ls = ngx_array_push (& cycle- > listening); if (ls = = NULL) {return NGX_ERROR;} ngx_memzero (ls, sizeof (ngx_listening_t)); ls- > fd = (ngx_socket_t) s;}}. Ngx_inherited = 1; return ngx_set_inherited_sockets (cycle);}

The function flow is as follows:

Parse the value of the environment variable NGINX_VAR to get the fd stored in the array

The socket corresponding to fd is set to ngx_inherited to save the information of these socket.

In other words, the new server does not re-bind the port listen at all. These fd states and values are brought by the new master process fork. The new master process listens to the inherited file descriptor. The key point here is that the listen socket file descriptor is passed through ENV.

The above is the whole content of this article, I hope it will be helpful to your study, and I also hope that you will support it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.