mirror of
https://github.com/apache/httpd.git
synced 2025-06-01 23:21:45 +03:00
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@103107 13f79535-47bb-0310-9956-ffa450edef68
203 lines
8.6 KiB
XML
203 lines
8.6 KiB
XML
<?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: 1.11 -->
|
|
|
|
<!--
|
|
Copyright 2003-2004 The Apache Software Foundation
|
|
|
|
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>
|