Capistrano는 Mongrel 클러스터를 올바르게 다시 시작하지 않습니다

Question

Nginx 아래에서 실행되는 3 개의 몬드 클러스터가 있으며 Capistrano 2.4.3을 사용하여 앱을 배포합니다. 실행중인 시스템이있을 때 "CAP 배포"하면 동작이 다음과 같습니다.

1. 앱이 배포되었습니다. 코드가 성공적으로 업데이트됩니다.

2. 캡 배포 출력에는 다음과 같습니다.

   • "sudo -p 'sudo password 실행 :'mongrel_rails cluster :: 다시 시작 -c /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • 서버 : [ "myip"
   • MYIP] 실행 명령
   • ** [out :: myip] 포트 중지 9096
   • ** [out :: myip] 포트 9097 중지
   • ** [out :: myip] 포트 9098 중지
   • ** [out :: myip] 이미 포트 9096을 시작했습니다.
   • ** [out :: myip] 이미 포트 9097을 시작했습니다.
   • ** [out :: myip] 이미 포트 9098을 시작했습니다.
3. 서버에서 즉시 확인하고 Mongrel이 여전히 실행 중인지 확인하고 PID 파일은 이전 세 인스턴스에 대해 여전히 존재합니다.
4. 짧은 시간 후 (1 분 미만) Mongrel이 더 이상 실행되지 않고 PID 파일이 사라지고 다시 시작하지 못했습니다.
5. 서버에서 수작업으로 Mongrel을 시작하면 앱이 잘 시작됩니다.

'mongrel_rails cluster :: 다시 시작'은 클러스터의 재시작을 시도하기 전에 전체 정지를 제대로 기다리지 않는 것 같습니다. 이 문제를 진단하고 수정하려면 어떻게해야합니까?

편집 : 다음은 답입니다.

Mongrel_Cluster는 "재시작"작업에서 간단히 수행합니다.

 def run
   stop
   start
 end

"시작"을 호출하기 전에 프로세스가 종료되었는지 확인하기 위해 기다리거나 확인하지 않습니다. 이것은 뛰어난 패치가 제출 된 알려진 버그. 패치를 Mongrel Cluster에 적용했고 문제가 사라졌습니다.

Answer 1

Capistrano 레시피에 다음을 추가하여 시작하기 전에 Mongrel_Cluster 레시피를 명시 적으로 알리기 전에 PID 파일을 제거 할 수 있습니다.

# helps keep mongrel pid files clean
set :mongrel_clean, true

이로 인해 -clean 옵션을 Mongrel_Cluster_CTL로 전달합니다.

나는 돌아가서 배포 레시피 중 하나를보고 재시작 작업이 작동하는 방식도 바뀌 었다는 것을 알았습니다. Mongrel 사용자 그룹의 다음 메시지를 살펴보십시오.

Mongrel 사용자 토론 재시작

다음은 내 배포입니다 : 다시 시작 작업. 나는 그것이 약간의 해킹임을 인정합니다.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 2

먼저, 전화만으로 테스트하는 범위를 좁 힙니다. cap deploy:restart. 당신은 통과하고 싶을 수도 있습니다 --debug 원격 실행 또는 원격 옵션 --dry-run 설정을 조정할 때 무슨 일이 일어나고 있는지 확인하기 위해 옵션.

언뜻보기에 이것은 PID 파일 또는 Mongrel 프로세스에 대한 권한 문제처럼 들리지만 확실히 알기가 어렵습니다. 내 눈을 사로 잡는 몇 가지는 다음과 같습니다.

• 그만큼 :runner 변수는 설명이 설정되어 있습니다 nil - 이에 대한 특별한 이유가 있었습니까?
• Capistrano 2.4는 새로운 행동을 소개했습니다 :admin_runner 변하기 쉬운. 전체 레시피를 보지 않고 이것은 문제와 관련이 있습니까?

  : 러너 대 : admin_runner (에서 Capistrano 2.4 릴리스) 일부 케이퍼는 배치 및 배포 : 설정 : 청소 실행 : 러너 사용자는 신중하게 제작 된 권한을 엉망으로 만들었습니다. 나는 이것이 문제라는 데 동의했다. 이 릴리스를 사용하면 배포 : 시작, 배포 : 중지 및 배포 : 다시 시작 : Sudoing이지만 배포 할 때 : 러너 사용자를 계속 사용하십시오 : 설정 및 배포 : Cleanup은 다음을 사용합니다. : admin_runner 변수는 기본적으로 설정되지 않으므로 해당 작업이 루트로 Sudo를 수행하지만 다음과 같이 실행하려면 : Runner, "Set : Admin_Runner, Runner"를 수행합니다.

다음에해야 할 일에 대한 나의 추천. 몽 그렐을 수동으로 멈추고 PID를 정리하십시오. 몽 그렐을 수동으로 시작하십시오. 다음으로, 계속 실행하십시오 cap deploy:restart 문제를 디버깅하는 동안. 필요에 따라 반복하십시오.

Answer 3

어느 쪽이든, 내 몽 그렐은 이전 중지 명령이 끝나기 전에 시작됩니다.

수면 2.5는 좋은 솔루션이 아닙니다. 모든 러닝 몬드를 중단하는 데 2.5 초 이상이 걸리면 2.5 초가 걸립니다.

필요가있는 것 같습니다.

stop && start

vs.

stop; start

(이것은 Bash의 작동 방식이며 && 첫 번째 명령이 오류없이 오류가 끝나기를 기다리는 동안 ";"다음 명령을 실행합니다).

나는 다음이 있는지 궁금합니다.

wait cluster_stop
then cluster_start

Answer 4

나는 너무 기본적인 것을 싫어하지만 PID 파일이 시작하려고 할 때 여전히 매달려있는 것처럼 들립니다. Mongrel이 손으로 멈춰야합니다. PID 파일을 손으로 정리하십시오. 그런 다음 캡 배포를하십시오.

Answer 5

좋은 토론 : http://www.ruby-forum.com/topic/139734#745030