1018
|
1 <!--
|
|
2 Copyright (C) Igor Sysoev
|
|
3 Copyright (C) Nginx, Inc.
|
|
4 -->
|
|
5
|
|
6 <!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
|
|
7
|
|
8 <article name="Controllo di nginx"
|
|
9 link="/it/docs/control.html"
|
|
10 lang="it"
|
|
11 translator="Angelo Papadia"
|
|
12 rev="5">
|
|
13
|
|
14 <section>
|
|
15
|
|
16 <para>
|
|
17 nginx puo' essere controllato tramite segnali.
|
|
18 L'ID del processo master e' scritto per default nel file
|
|
19 <path>/usr/local/nginx/logs/nginx.pid</path>.
|
|
20 E' possibile utilizzare un altro file utilizzando la direttiva
|
|
21 <link doc="ngx_core_module.xml" id="pid"/>, definendola all'avvio
|
|
22 oppure in <path>nginx.conf</path> .
|
|
23 Il processo master riconosce i seguenti segnali:
|
|
24 <note>
|
|
25 <table>
|
|
26
|
|
27 <tr><td width="20%">TERM, INT</td><td>arresto rapido</td></tr>
|
|
28 <tr><td width="20%">QUIT</td><td>arresto controllato</td></tr>
|
|
29 <tr><td width="20%">HUP</td><td>ricaricamento della configurazione,
|
|
30 allineamento ad una diversa zona oraria (solo per FreeBSD e Linux),
|
|
31 riavvio di nuovi processi worker con una nuova configurazione,
|
|
32 spegnimento controllato dei vecchi processi worker</td></tr>
|
|
33 <tr><td width="20%">USR1</td><td>riapertura dei file di log</td></tr>
|
|
34 <tr><td width="20%">USR2</td><td>aggiornamento del file eseguibile</td></tr>
|
|
35 <tr><td width="20%">WINCH</td><td>arresto controllato dei processi worker</td></tr>
|
|
36
|
|
37 </table>
|
|
38 </note>
|
|
39 </para>
|
|
40
|
|
41 <para>
|
|
42 E' anche possibile controllare ciascun processo worker,
|
|
43 per quanto cio' non sia richiesto.
|
|
44 I segnali riconosciuti sono:
|
|
45 <note>
|
|
46 <table>
|
|
47
|
|
48 <tr><td width="20%">TERM, INT</td><td>arresto rapido</td></tr>
|
|
49 <tr><td width="20%">QUIT</td><td>arresto controllato</td></tr>
|
|
50 <tr><td width="20%">USR1</td><td>riapertura dei file di log</td></tr>
|
|
51 <tr><td width="20%">WINCH</td><td>chiusura anomala per debugging
|
|
52 (richiede <link doc="ngx_core_module.xml" id="debug_points"/> )
|
|
53 </td></tr>
|
|
54
|
|
55 </table>
|
|
56 </note>
|
|
57 </para>
|
|
58
|
|
59 </section>
|
|
60
|
|
61
|
|
62 <section id="reconfiguration" name="Cambio della configurazione">
|
|
63
|
|
64 <para>
|
|
65 Per far rileggere la configurazione a nginx, bisogna inviare
|
|
66 un segnale HUP al processo master.
|
|
67 Tale processo per prima cosa verifica la validita' sintattica
|
|
68 della nuova configurazione, quindi tenta di applicarla, vale a dire
|
|
69 di aprire i file di log e i nuovi socket di ascolto.
|
|
70 In caso di fallimento, annulla i cambiamenti e continua a lavorare
|
|
71 con la vecchia configurazione.
|
|
72 Invece, in caso di successo, avvia nuovi processi worker e invia a
|
|
73 quelli vecchi appositi segnali per chiederne l'arresto controllato.
|
|
74 I vecchi processi chiudono i socket di ascolto, ma continuano il
|
|
75 servizio per i vecchi client.
|
|
76 Quanto tutti i vecchi client sono stati servizi, i vecchi
|
|
77 processi worker terminano.
|
|
78 </para>
|
|
79
|
|
80 <para>
|
|
81 Di seguito si illustra con un esempio.
|
|
82 Si immagini che nginx sia in esecuzione su FreeBSD 4.x
|
|
83 e che il comando
|
|
84 <programlisting>
|
|
85 ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'
|
|
86 </programlisting>
|
|
87 produca il seguente risultato:
|
|
88 <programlisting>
|
|
89 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
90 33126 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
91 33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx)
|
|
92 33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
93 33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
94 </programlisting>
|
|
95 </para>
|
|
96
|
|
97 <para>
|
|
98 Se al processo master si invia il segnale HUP, si ottiene:
|
|
99 <programlisting>
|
|
100 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
101 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
102 33129 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx)
|
|
103 33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
104 33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
105 33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
106 </programlisting>
|
|
107 </para>
|
|
108
|
|
109 <para>
|
|
110 Uno dei vecchi processi worker con PID 33129 continua ad essere attivo;
|
|
111 dopo un po', esce:
|
|
112 <programlisting>
|
|
113 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
114 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
115 33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
116 33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
117 33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
118 </programlisting>
|
|
119 </para>
|
|
120
|
|
121 </section>
|
|
122
|
|
123
|
|
124 <section id="logs" name="Rotazione dei file di log">
|
|
125
|
|
126 <para>
|
|
127 Per poter ruotare i file di log, e' prima necessario cambiare loro il nome,
|
|
128 quindi bisogna inviare il segnale USR1 al processo master,
|
|
129 il quale provvede a riaprire tutti i file di log correnti e ad
|
|
130 assegnarli all'utente non privilegiato sotto i quali sono in
|
|
131 esecuzione i processi worker.
|
|
132 Dopo aver riaperto con successo i file, il processo master chiude tutti
|
|
133 i file aperti, ed invia un messaggio ai processi worker per chiedere loro
|
|
134 di riaprire i file; i processi worker provvedono quindi immediatamente
|
|
135 ad aprire i nuovi file ed a chiudere i vecchi.
|
|
136 Come risultato, i vecchi file sono quasi immediatamente disponibili per
|
|
137 eventuali attivita' successive, ad esempio per la compressione.
|
|
138 </para>
|
|
139
|
|
140 </section>
|
|
141
|
|
142
|
|
143 <section id="upgrade" name="Aggiornamento al volo del file eseguibile">
|
|
144
|
|
145 <para>
|
|
146 Per poter aggiornare l'eseguibile del server, prima e' necessario
|
|
147 porre il nuovo file al posto del vecchio; dopo, bisogna inviare al
|
|
148 processo master il segnale USR2.
|
|
149 Il processo master provvede a rinominare il file contenente il proprio
|
|
150 ID di processo, aggiungendo il suffisso <path>.oldbin</path>, ad
|
|
151 esempio <path>/usr/local/nginx/logs/nginx.pid.oldbin</path>,
|
|
152 quindi avvia un nuovo file eseguibile, che a sua volta fa partire i
|
|
153 propri processi worker:
|
|
154 <programlisting>
|
|
155 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
156 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
157 33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
158 33135 33126 nobody 0.0 1380 kqread nginx: worker process (nginx)
|
|
159 33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx)
|
|
160 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
161 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
162 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
163 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
164 </programlisting>
|
|
165 </para>
|
|
166
|
|
167 <!--
|
|
168
|
|
169 <para>
|
|
170 Il processo 36264 relativo ad un nuovo file eseguibile crea il proprio file
|
|
171 con l'ID di processo, aggiungendo il suffisso <path>.newbin</path>,
|
|
172 ad esempio <path>/usr/local/nginx/logs/nginx.pid.newbin</path>.
|
|
173 </para>
|
|
174
|
|
175 -->
|
|
176
|
|
177 <para>
|
|
178 A questo punto, sia i processi worker relativi al vecchio eseguibile, sia quelli
|
|
179 relativi al nuovo, accettano richieste.
|
|
180 Se al processo master e' inviato il segnale WINCH, tutti i relativi processi
|
|
181 worker ricevono a loro volta un segnale che chiede loro l'arresto controllato,
|
|
182 e quindi iniziano a spegnersi:
|
|
183 <programlisting>
|
|
184 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
185 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
186 33135 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx)
|
|
187 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
188 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
189 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
190 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
191 </programlisting>
|
|
192 </para>
|
|
193
|
|
194 <para>
|
|
195 <note>
|
|
196 Quando su Linux si usa il metodo "rtsig", i nuovi processi potrebbero non
|
|
197 accettare connessioni anche dopo che al processo master vecchio e' stato
|
|
198 inviato il segnale WINCH.
|
|
199 In tal caso, bisogna continuare ad inviare il segnale USR1 al nuovo processo
|
|
200 master, sinche' i nuovi processi iniziano ad accettare connessioni.
|
|
201 </note>
|
|
202 </para>
|
|
203
|
|
204 <para>
|
|
205 In breve, i soli processi worker a processare le richieste saranno quelli nuovi:
|
|
206 <programlisting>
|
|
207 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
208 33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
209 36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
210 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
211 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
212 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
213 </programlisting>
|
|
214 </para>
|
|
215
|
|
216 <para>
|
|
217 Si noti che il vecchio processo master non chiude i suoi socket di ascolto,
|
|
218 e che se necessario e' possibile chiedergli di riavviare i propri
|
|
219 processi worker.
|
|
220 Se per qualche ragione il nuovo file eseguibile non lavora correttamente,
|
|
221 e' possibile procedere in due modi:
|
|
222 <list type="bullet">
|
|
223
|
|
224 <listitem>
|
|
225 <para>
|
|
226 inviare il segnale HUP al vecchio processo master.
|
|
227 Il vecchio processo master provvedera' ad avviare
|
|
228 nuovi processi worker, senza rileggere la configurazione.
|
|
229 A questo punto, tutti i nuovi processi possono essere fermati
|
|
230 in maniera controllata, inviando il segnale QUIT al nuovo
|
|
231 processo master.
|
|
232 </para>
|
|
233 </listitem>
|
|
234
|
|
235 <listitem>
|
|
236 <para>
|
|
237 inviare il segnale TERM al nuovo processo master.
|
|
238 Tale processo inviare a sua volta un messaggio ai suoi processi
|
|
239 worker che causera' la loro chiusura immediata.
|
|
240 (Se per qualche ragione i nuovi processi non terminano, e'
|
|
241 possibile inviare loro il segnale KILL per forzarne la chiusura.)
|
|
242 Quando il nuovo processo master si e' chiuso, il vecchio processo
|
|
243 master provvedera' immediatamente ad avviare nuovi processi worker.
|
|
244 </para>
|
|
245 </listitem>
|
|
246
|
|
247 </list>
|
|
248
|
|
249 </para>
|
|
250
|
|
251 <para>
|
|
252 Se il nuovo processo master termina, allora in vecchio processo master
|
|
253 provvede a cancellare il suffisso <path>.oldbin</path> dal nome del file
|
|
254 contenente l'ID del processo.
|
|
255 </para>
|
|
256
|
|
257 <para>
|
|
258 Se l'aggiornamento ha successo, al vecchio processo master dovrebbe
|
|
259 essere inviato il segnale QUIT, in maniera che rimangano solo i
|
|
260 processi nuovi:
|
|
261 <programlisting>
|
|
262 PID PPID USER %CPU VSZ WCHAN COMMAND
|
|
263 36264 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx
|
|
264 36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
265 36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
266 36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx)
|
|
267 </programlisting>
|
|
268 </para>
|
|
269
|
|
270 <!--
|
|
271
|
|
272 <para>
|
|
273 Per completare il processo di aggiornamento, il file
|
|
274 <path>/usr/local/nginx/logs/nginx.pid.newbin</path> dovrebbe essere rinominato
|
|
275 <path>/usr/local/nginx/logs/nginx.pid</path>.
|
|
276 </para>
|
|
277
|
|
278 -->
|
|
279
|
|
280 </section>
|
|
281
|
|
282 </article>
|