매일 일정시간에 뻗어버리는 apache

해결책은 안 떠오릅니다만,

일단 크론으로 process status(ps)를 계속 로그를 해주면서 어떤 일정한 시간 혹은 어떤 순간에 프로세스가 죽는지 한번 체크해보십시오. 아무런 대답을 바로 찾을 수 없을 때는 최대한 많은 정보를 모으는게 해결책으로 한걸음 다가가는 것이 아닐런지..

별 도움이 안될지도 모르지만..

제가 경험한 경우는 이런 것이었습니다.

아직 불안정 버전이던 데비안 우디를 powerpc에서 돌리고 있었는데 어느날 php가 4.1로 업그레이드 되면서 갑자기 php의 session 기능이 동작하지 않았습니다. 이리 저리 테스트해 보고 버그 리스트도 살펴보고 하다가 아무래도 새로운 php 패키지의 버그인 것 같아서 버그를 보고하고 감자의 php와 아파치로 다운그레이드 해놓고 있었습니다.(아파치는 의존성이 걸려서 함께 다운그레이드)

그리고 나중에 버그 리스트에 임시 땜방용 방법이 올라왔는데 php.ini 설정에서 session 관련 옵션을 조정하는 방법이었습니다. session 기록을 메모리에 유지하지 않고 /tmp 파일에 쓰는 옵션이던가 뭐 그런 것이었는데, 일단 이 방법으로 session 기능이 잘 되는 것을 확인하고 기쁜 마음으로 다시 php를 4.1로 업했는데.. 좀 지나고 보니 페이지에 접근할때 수시로 접속이 끊어지는 현상이 한동안 계속되고, 나중에는 아파치 자체가 프로세스 리스트에서 사라져 있더군요!

그래서 아파치 로그를 살펴보니까 php 모듈이 에러를 내면서 아파치가 segmentation fault를 내고 계속 죽어 나가더군요. 그래서 눈물을 머금고 다시 php와 아파치를 다운그레이드 했습니다.

버그 리포트에 따르면 이 문제는 powerpc와 sparc에서 같이 발생하는 문제였고, 거의 일년 가까이 해결되지 않다가 우디가 안정버전 되고 나서도 한참 있다가 해결되었는데 문제의 원인은 php가 아니라 glibc의 버그에 있었다고 하더군요. 무슨 리틀 엔디안이 어떻고 빅 엔디안이 어떻고 그런 이야기가 나오던데.. 어려운 얘기는 잘 모르겠습니다 ~_~

그래서 요약하자면 -_-; 제가 경험한 경우는 php 모듈의 문제로 아파치가 죽어 나가던 경우였고, 에러 로그에 기록이 명확히 남아 있어서 그냥 다운그레이드하는 방법이라도 쓸 수가 있었다는 이야기입니다;;

그러나 무진장 널리 쓰이는 i386에서 이런 류의 문제가 있을 수 있다고는 생각하기 어려울 것 같네요. 이런 심각한 문제는 금방 발견이 되고 고쳐졌을 테니까 말이지요. 아마 새 기계에서 깨끗하게 다시 깔고 시작하면 잘 되지 않을까요? :roll: kldp.net 서비스 중단 기념으로 적어보았습니다 ㅡ.ㅡ;

core파일을 만들게 하셔서 살펴보시는게 좋을거 같습니다만...

message로그에도 아무 기록이 없나요?

시스템 관리자들은 그 이유때문에, 항상 최신버전 업그레이드를
주저합니다. 어느 정도 안정된 버전임이 확인되면 그때 이행하지요.
물론 크리티컬한 에러라고 한다면 달라지겠지만..

쩝.. 왜 잠은 안오는거야..