이전에 SSH를 통해 원격으로 시스템을 종료한 적이 있지만 동기화 sudo service ... stop되었는지 몰랐고 stopUbuntu 시스템을 너무 빨리 종료했는지 궁금했습니다.
그렇다면 내 두려움은 잘못된 예감에 기초한 것일까요?
편집: 내 서비스는 포트에서 청취 콘텐츠를 수신한 다음 수시로 데이터베이스에 콘텐츠를 쓰는 개인 서비스입니다. 서비스가 갑자기 중단되면 새로 고칠 시간이 없을까 걱정됩니다. stop비워내는 일을 담당하고 있지만 생각해보면 시간이 걸릴 수도 있겠네요...
답변1
신청서를 확인하세요
- 시스템 로그에 적절한 종료를 기록합니다.
man 3 syslog자세한 내용은 참조하세요. - 데이터베이스에 필요한 모든 것을 쓰고, 연결을 닫고, 자세한 내용은
exiting을 통해 SIGTERM을 처리합니다.man 2 sigaction - /etc/init.d에 작업 중지 핸들러가 있습니다
man init.man stopping
그러면 애플리케이션이 올바르게 중지되었는지 추측할 필요 없이 그냥 알 수 있습니다.
답변2
서비스가 어떻게 중지되었는지에 따라 다릅니다. 오직 당신만이 알고 있습니다. 서비스 시작 및 중지 방법은 서비스 사용자를 위해 문서화하고 제공하는 것이 좋습니다.
kill쉘 스크립트 호출에서 신호를 보내 서비스가 중지된 경우 이는 비동기입니다. 명령 kill이나 시스템 호출은 프로세스에 신호를 보내고 즉시 반환됩니다. 프로세스가 신호를 만족스럽게 처리했음을 알리기 위해 다시 호출하는 메커니즘은 없습니다. 따라서 완료되었음을 보여줄 다른 방법을 찾아야 합니다.
서비스에서 파일을 생성 또는 삭제하고 제어 스크립트에서 해당 파일의 변경 사항을 모니터링하는 등 다양한 접근 방식이 가능합니다. 그러나 그들은 종종 어색합니다. 서비스 완료 시 피드백이 필요한 경우 관련 없는 프로세스에 신호를 보내는 것은 좋은 접근 방식이 아닙니다.
Upstart 서비스 설명의 지침에 따라 서비스가 중지되면 stopUpstart는 프로세스에 신호를 보냅니다. 그런 다음 Upstarts는 프로세스가 중지될 때까지 몇 초 동안 기다립니다. Upstart는 프로세스의 상위 프로세스이므로 프로세스가 종료될 때 커널로부터 알림(SIGCLD 신호)을 받습니다. 이 방법은 프로세스가 백그라운드로 전환되지 않는 경우에만 작동합니다. Upstart 서비스 설명은 일반적으로 포크하지 말라고 지시하는 옵션을 사용하여 데몬을 호출합니다(예: ssh -D).
고급 서비스에는 제한 명령이 있습니다. 제한 명령을 호출하면 새 연결 수락이 중지됩니다. 보류 중인 모든 연결이 닫히면 서비스는 제한 명령에 긍정적인 응답을 보낸 다음 종료됩니다. 통신 방법은 일반적으로 Unix 또는 IP 소켓입니다.