중단과 재시작

소개

아파치를 중단하고 재시작하려면 실행하고 있는 httpd 프로세스에 시그널을 보내야 한다. 시그널을 보내는 방법은 두가지다. 하나는 유닉스 kill 명령어를 사용하여 프로세스에 직접 시그널을 보내는 방법이다. 시스템에 많은 httpd가 실행되지만, PidFile에 pid가 기록된 부모외에 다른 프로세스에 시그널(signal)을 보내면 안된다. 즉, 부모이외에 다른 프로세스에 시그널을 보낼 필요가 없다는 말이다. 부모에게 보낼 수 있는 시그널은 세가지로, 이제 설명할 TERM, HUP, USR1이다.

다음과 같이 부모에게 시그널을 보낸다:

httpd 프로세스에게 시그널을 보내는 다른 방법은 명령행 옵션 -k를 사용하는 것이다. 아래서 설명할 stop, restart, graceful은 httpd 실행파일의 아규먼트들이다. 그러나 이 아규먼트들로 httpd를 실행하는, apachectl 스크립트를 사용하길 권한다.

httpd에 시그널을 보낸후, 다음 명령어로 진행상황을 알 수 있다:

위 예를 당신의 ServerRoot와 PidFile 설정에 알맞게 수정하라.

당장 중단

시그널: TERM

apachectl -k stop

TERM이나 stop 시그널을 부모에게 보내면 즉시 모든 자식을 죽인다. 자식을 완전히 죽이는데는 몇 초가 걸릴 수 있다. 그런후 부모가 종료한다. 처리중인 요청은 중단되고, 더 이상 요청을 받지않는다.

점잖은 재시작

시그널: USR1

apachectl -k graceful

USR1이나 graceful 시그널을 부모에게 보내면 부모 프로세스는 자식들에게 현재 요청을 처리한후 종료하라고 (혹은 현재 아무것도 처리하지 않다면 즉시 종료하라고) 조언한다. 부모는 설정파일을 다시읽고 로그파일도 다시 연다. 자식이 죽을때마다 부모는 죽은 자식대신 새로운 설정 세대에 기초한 자식을 실행하여 즉시 요청을 처리하게 한다.

점잖은 재시작은 항상 MPM의 프로세스 조절 지시어 설정을 고려하여, 재시작동안 클라이언트를 서비스하는 프로세스나 쓰레드가 적당한 수를 유지하도록 설계되었다. 게다가 StartServers는, 일초 후 최소한 StartServers만큼 새로운 자식이 안만들어지면 자식이 StartServers 개가 되도록 새로 만든다. 즉, 프로그램은 서버의 현재 부하에 알맞은 자식의 개수를 유지하며, StartServers 파라미터로 지정한 당신의 기대를 존중한다.

mod_status 사용자는 USR1을 받을때 서버 통계가 0이 되지 않음을 봤을 것이다. 서버는 새로운 요청을 (운영체제는 이들을 큐에 담아서 어떤 경우에도 잃어버리지 않는다) 처리하지 못하는 시간을 최소화하고 당신의 튜닝 파라미터를 존중하도록 만들어졌다. 이를 위해 세대간 모든 자식을 기록하는 scoreboard를 유지한다.

status 모듈은 또한 점잖은 재시작 전에 시작하여 아직도 요청을 처리하고 있는 자식을 G로 알려준다.

현재로는 USR1을 사용하는 로그순환 스크립트가 재시작전에 모든 자식이 로그작성을 마쳤는지 알 수 있는 방법이 없다. 우리는 USR1 시그널을 보내고 적당한 시간이 지난후 이전 로그를 다루도록 제안한다. 예를 들어 낮은 대역폭 사용자의 경우 접속 대부분이 마치는데 10분이 안걸린다면, 이전 로그를 다루기전에 15분 기다린다.

당장 재시작

시그널: HUP

apachectl -k restart

HUP이나 restart 시그널을 부모에게 보내면 TERM과 같이 모든 자식을 죽이지만 부모는 종료하지 않는다. 부모는 설정파일을 다시읽고 로그파일을 다시 연다. 그리고 새로운 자식들을 만들고 서비스를 계속한다.

mod_status 사용자는 HUP를 보내면 서버 통계가 0이 됨을 알 수 있다.

부록: 시그널과 레이스 컨디션

Apache 1.2b9 이전에는 재시작과 종료 시그널에 관계된 레이스 컨디션(race condition)이 있었다. (레이스 컨디션은 간단한 설명하자면, 어떤 일이 잘못된때 일어나서 기대한대로 동작하지 않는 시간에 민감한 문제다.) "올바른" 기능이 있는 아키텍쳐에서 우리는 이런 문제를 최대한 해결했다. 그러나 어떤 아키텍쳐에는 아직도 레이스 컨디션이 존재함을 주의하라.

ScoreBoardFile을 디스크에 저장하는 아키텍쳐는 scoreboard를 망가트릴 가능성이 있다. 그러면 (HUP후) "bind: Address already in use" 혹은 (USR1 후) "long lost child came home!"이 발생할 수 있다. 전자는 심각한 오류이고, 후자는 단지 서버가 scoreboard slot을 잃게 만든다. 그래서 강제 재시작을 줄이고 점잖은 재시작을 사용하길 추천한다. 이 문제는 해결하기 매우 힘들다. 그러나 다행히도 대부분의 아키텍쳐는 scoreboard로 파일을 사용하지 않는다. 파일을 사용하는 아키텍쳐라면 ScoreBoardFile 문서를 참고하라.

모든 아키텍쳐에는 지속되는 HTTP 연결 (KeepAlive)에서 두번째 이후 요청을 처리하는 자식에 약간의 레이스 컨디션이 있다. 자식은 요청줄을 읽은 후 요청 헤더를 읽기전에 종료할 수 있다. 이 문제는 너무 늦게 발견하여 1.2 버전이 나온후에야 수정되었다. 그러나 네트웍 지연이나 서버 시간제한때문에 KeepAlive 클라이언트는 이런 경우를 예상해야하기 때문에 이론상 문제는 안된다. 실제로 서버를 검사하기위해 일초에 20번 재시작하는 동안 클라이언트가 깨진 그림이나 빈 문서없이 사이트를 성공적으로 읽어들이길 기대하지 않는다면 문제가 안된다.