1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
<?xml version='1.0' encoding='EUC-KR' ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
<!-- English Revision: 105989:264737 (outdated) -->
<!--
Copyright 2003-2006 The Apache Software Foundation or its licensors,
as applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="stopping.xml.meta">
<title>중단과 재시작</title>
<summary>
<p>이 문서는 유닉스류 시스템에서 아파치를 중단하고 재시작하는
내용을 담고있다. 윈도우즈 NT, 2000, XP 사용자는 <a
href="platform/windows.html#winsvc">서비스로 아파치
실행하기</a>에서, 윈도우즈 9x와 ME 사용자는 <a
href="platform/windows.html#wincons">콜솔 프로그램으로
아파치 실행하기</a>에서 플래폼별 아파치 조작법을 알 수 있다.</p>
</summary>
<seealso><a href="programs/httpd.html">httpd</a></seealso>
<seealso><a href="programs/apachectl.html">apachectl</a></seealso>
<section id="introduction"><title>소개</title>
<p>아파치를 중단하고 재시작하려면 실행하고 있는
<code>httpd</code> 프로세스에 시그널을 보내야 한다. 시그널을
보내는 방법은 두가지다. 하나는 유닉스 <code>kill</code>
명령어를 사용하여 프로세스에 직접 시그널을 보내는 방법이다.
시스템에 많은 <code>httpd</code>가 실행되지만, <directive
module="mpm_common">PidFile</directive>에 pid가 기록된 부모외에
다른 프로세스에 시그널(signal)을 보내면 안된다. 즉, 부모이외에
다른 프로세스에 시그널을 보낼 필요가 없다는 말이다. 부모에게
보낼 수 있는 시그널은 세가지로, 이제 설명할 <code><a
href="#term">TERM</a></code>, <code><a
href="#hup">HUP</a></code>, <code><a
href="#graceful">USR1</a></code>이다.</p>
<p>다음과 같이 부모에게 시그널을 보낸다:</p>
<example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example>
<p><code>httpd</code> 프로세스에게 시그널을 보내는 다른 방법은
명령행 옵션 <code>-k</code>를 사용하는 것이다. 아래서 설명할
<code>stop</code>, <code>restart</code>, <code>graceful</code>은
<a href="programs/httpd.html">httpd</a> 실행파일의 아규먼트들이다.
그러나 이 아규먼트들로 <code>httpd</code>를 실행하는, <a
href="programs/apachectl.html">apachectl</a> 스크립트를
사용하길 권한다.</p>
<p><code>httpd</code>에 시그널을 보낸후, 다음 명령어로
진행상황을 알 수 있다:</p>
<example>tail -f /usr/local/apache2/logs/error_log</example>
<p>위 예를 당신의 <directive
module="core">ServerRoot</directive>와 <directive
module="mpm_common">PidFile</directive> 설정에 알맞게 수정하라.</p>
</section>
<section id="term"><title>당장 중단</title>
<dl><dt>시그널: TERM</dt>
<dd><code>apachectl -k stop</code></dd>
</dl>
<p><code>TERM</code>이나 <code>stop</code> 시그널을 부모에게
보내면 즉시 모든 자식을 죽인다. 자식을 완전히 죽이는데는
몇 초가 걸릴 수 있다. 그런후 부모가 종료한다. 처리중인 요청은
중단되고, 더 이상 요청을 받지않는다.</p>
</section>
<section id="graceful"><title>점잖은 재시작</title>
<dl><dt>시그널: USR1</dt>
<dd><code>apachectl -k graceful</code></dd>
</dl>
<p><code>USR1</code>이나 <code>graceful</code> 시그널을
부모에게 보내면 부모 프로세스는 자식들에게 현재 요청을
처리한후 종료하라고 (혹은 현재 아무것도 처리하지 않다면
즉시 종료하라고) <em>조언한다</em>. 부모는 설정파일을
다시읽고 로그파일도 다시 연다. 자식이 죽을때마다 부모는
죽은 자식대신 새로운 설정 <em>세대</em>에 기초한 자식을
실행하여 즉시 요청을 처리하게 한다.</p>
<note>점잖은 재시작(graceful restart)으로 <code>USR1</code>을
사용할 수 없는 플래폼에서는 대신 (<code>WINCH</code>와 같은)
다른 시그널을 사용할 수 있다. <code>apachectl graceful</code>은
플래폼에 알맞은 시그널을 보낸다.</note>
<p>점잖은 재시작은 항상 MPM의 프로세스 조절 지시어 설정을
고려하여, 재시작동안 클라이언트를 서비스하는 프로세스나 쓰레드가
적당한 수를 유지하도록 설계되었다. 게다가 <directive
module="mpm_common">StartServers</directive>는, 일초 후
최소한 StartServers만큼 새로운 자식이 안만들어지면 자식이
StartServers 개가 되도록 새로 만든다. 즉, 프로그램은 서버의
현재 부하에 알맞은 자식의 개수를 유지하며,
<directive>StartServers</directive> 파라미터로 지정한 당신의
기대를 존중한다.</p>
<p><module>mod_status</module> 사용자는 <code>USR1</code>을
받을때 서버 통계가 0이 되지 <strong>않음을</strong> 봤을
것이다. 서버는 새로운 요청을 (운영체제는 이들을 큐에 담아서
어떤 경우에도 잃어버리지 않는다) 처리하지 못하는 시간을
최소화하고 당신의 튜닝 파라미터를 존중하도록 만들어졌다.
이를 위해 세대간 모든 자식을 기록하는 <em>scoreboard</em>를
유지한다.</p>
<p>status 모듈은 또한 점잖은 재시작 전에 시작하여 아직도
요청을 처리하고 있는 자식을 <code>G</code>로 알려준다.</p>
<p>현재로는 <code>USR1</code>을 사용하는 로그순환 스크립트가
재시작전에 모든 자식이 로그작성을 마쳤는지 알 수 있는
방법이 없다. 우리는 <code>USR1</code> 시그널을 보내고
적당한 시간이 지난후 이전 로그를 다루도록 제안한다. 예를
들어 낮은 대역폭 사용자의 경우 접속 대부분이 마치는데 10분이
안걸린다면, 이전 로그를 다루기전에 15분 기다린다.</p>
<note>설정파일에 오류가 있다면 재시작시 부모는 재시작하지
않고 오류를 내며 종료한다. 또, 점잖은 재시작의 경우 종료할때
자식이 실행되도록 놔둔다. (자식들은 자신의 마지막 요청을
처리하고 "점잖게 종료한다".) 이는 서버를 재시작할때
문제가 된다. 서버는 자신이 기다릴 포트에 연결하지 못한다.
재시작전에 <code>-t</code> 명령행 옵션(<a
href="programs/httpd.html">httpd</a> 참고)으로 설정파일
문법을 검사할 수 있다. 그러나 이런 검사도 서버가 올바로
재시작할지를 보장하지 못한다. 설정파일의 문법이 아닌 의미를
검사하려면 root가 아닌 사용자로 <code>httpd</code>를 시작해볼 수 있다.
root가 아니기때문에 (아니면 현재 그 포트를 사용하는
<code>httpd</code>가 실행되기때문에) 오류가 없다면 소켓과
로그파일을 열려고 시도하는 과정에서 실패할 것이다. 다른
이유때문에 실패한다면 아마도 설정파일에 오류가 있을 것이다.
점잖은 재시작을 하기전에 오류를 고쳐야한다.</note>
</section>
<section id="hup"><title>당장 재시작</title>
<dl><dt>시그널: HUP</dt>
<dd><code>apachectl -k restart</code></dd>
</dl>
<p><code>HUP</code>이나 <code>restart</code> 시그널을
부모에게 보내면 <code>TERM</code>과 같이 모든 자식을
죽이지만 부모는 종료하지 않는다. 부모는 설정파일을 다시읽고
로그파일을 다시 연다. 그리고 새로운 자식들을 만들고 서비스를
계속한다.</p>
<p><module>mod_status</module> 사용자는 <code>HUP</code>를
보내면 서버 통계가 0이 됨을 알 수 있다.</p>
<note>설정파일에 오류가 있다면 재시작을 해도 부모는 재시작하지
않고 오류를 내며 종료할 것이다. 이를 피하는 방법은 위를 참고하라.</note>
</section>
<section id="race"><title>부록: 시그널과 레이스 컨디션</title>
<p>Apache 1.2b9 이전에는 재시작과 종료 시그널에 관계된
<em>레이스 컨디션(race condition)</em>이 있었다. (레이스
컨디션은 간단한 설명하자면, 어떤 일이 잘못된때 일어나서
기대한대로 동작하지 않는 시간에 민감한 문제다.) "올바른"
기능이 있는 아키텍쳐에서 우리는 이런 문제를 최대한 해결했다.
그러나 어떤 아키텍쳐에는 아직도 레이스 컨디션이 존재함을
주의하라.</p>
<p><directive module="mpm_common">ScoreBoardFile</directive>을
디스크에 저장하는 아키텍쳐는 scoreboard를 망가트릴 가능성이
있다. 그러면 (<code>HUP</code>후) "bind: Address already in use"
혹은 (<code>USR1</code> 후) "long lost child came home!"이
발생할 수 있다. 전자는 심각한 오류이고, 후자는 단지 서버가
scoreboard slot을 잃게 만든다. 그래서 강제 재시작을 줄이고
점잖은 재시작을 사용하길 추천한다. 이 문제는 해결하기 매우
힘들다. 그러나 다행히도 대부분의 아키텍쳐는 scoreboard로 파일을
사용하지 않는다. 파일을 사용하는 아키텍쳐라면 <directive
module="mpm_common">ScoreBoardFile</directive> 문서를 참고하라.</p>
<p>모든 아키텍쳐에는 지속되는 HTTP 연결 (KeepAlive)에서
두번째 이후 요청을 처리하는 자식에 약간의 레이스 컨디션이
있다. 자식은 요청줄을 읽은 후 요청 헤더를 읽기전에 종료할 수
있다. 이 문제는 너무 늦게 발견하여 1.2 버전이 나온후에야
수정되었다. 그러나 네트웍 지연이나 서버 시간제한때문에 KeepAlive
클라이언트는 이런 경우를 예상해야하기 때문에 이론상 문제는
안된다. 실제로 서버를 검사하기위해 일초에 20번 재시작하는 동안
클라이언트가 깨진 그림이나 빈 문서없이 사이트를 성공적으로
읽어들이길 기대하지 않는다면 문제가 안된다.</p>
</section>
</manualpage>
|
