Mercurial > hg > nginx-site

comparison xml/it/docs/control.xml @ 1018:19129672444e

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Added italian translation. Grazie a Angelo Papadia <angelo.papadia@gmail.com>!
author Vladimir Homutov <vl@nginx.com>
date Wed, 20 Nov 2013 14:36:40 +0400
parents
children
comparison
equal deleted inserted replaced
1017:9f9a427a73eb 1018:19129672444e
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>