저는 Linux 기반 임베디드 시스템에서 Python을 사용하여 다양한 서비스를 구현해 왔습니다. 시스템이 시작된 후 영원히 실행되어야 하는 드라이버 서비스가 있습니다. 시간이 지나면 다른 서비스를 하위 프로세스로 생성하고 루프의 이 부분을 계속합니다. 제가 달성하고 싶은 가장 중요한 점은 시스템이 종료되지 않는 한 이 드라이버 서비스가 절대 멈추지 않는다는 것입니다. 다음과 같은 옵션이 있습니다.
- 이 서비스를 시스템 데몬으로 만들고 계속 실행하세요.
- 이 서비스를 일반 프로세스로 시작하고 계속 실행하세요.
어떤 옵션을 선택해야 하며 그 이유는 무엇입니까? 또한 이 두 가지 접근 방식의 근본적인 차이점은 무엇입니까?
답변1
먼저 질문 제목을 다루겠습니다. 데몬 프로세스와 정상 실행 프로세스의 차이점은 대부분의 경우 "정상 프로세스"라고 말할 때 다음과 같은 사용자 입력/출력 API에 연결된 것을 의미한다는 것입니다. 텍스트 터미널(보통 파일 설명자 테이블에서 처음 3개의 파일 설명자를 열고 이를 일종의 가상 터미널에 연결) 또는 그래픽 사용자 인터페이스(보통 Linux 및 UNIX에서 X11 프로토콜 사용). 반면에 데몬은 일반적으로 터미널에서 분리되었거나 애초에 터미널에 연결되지 않은 프로세스를 나타냅니다.
문제 자체의 경우 데몬으로 실행하든 "일반 프로세스"로 실행하든 관계없이 애플리케이션이 충돌하고 다시 시작해야 할 수 있습니다. 프로세스가 일부 사용자 터미널에 연결되면 사용자는 실패를 감지하고 애플리케이션을 다시 시작할 수 있지만 데몬은 일반적으로 이 기능을 좋아하지 않습니다. 이로 인해 데몬이 터미널에서 연결이 끊어지면 실패 감지가 더 어려워집니다. 프로세스가 중단되었습니다.
이 문제를 해결하기 위해 우리는 서비스 관리 프레임워크를 개발했습니다. SysV, SystemD, Upstart, Supervisord, runit 등 다양한 기능을 갖춘 다양한 구현이 있습니다. 그들은 모두 하나의 매우 중요한 기능을 가지고 있습니다. 즉, 데몬을 시작하고(보통 부팅 시 자동으로) 실패할 때까지 모니터링한 다음 다시 시작하는 방법이 있습니다.
장치 드라이버 서비스를 실행하기 위해 서비스 관리 프레임워크를 사용해야 합니까? 반드시 이렇게 해야 합니다. 이것이 유일하게 합리적인 접근 방식입니다.
어떤 서비스 관리 소프트웨어를 사용할지는 어려운 질문입니다. 일반적으로 가장 좋은 방법은 운영 체제와 함께 번들로 제공되는 서비스 관리 소프트웨어를 사용하는 것입니다. 일반적으로 이 소프트웨어는 프로세스 ID 0으로 실행되며 커널에 의해 직접 시작됩니다. 현재 최신 Linux 기반 운영 체제에서 가장 눈에 띄는 소프트웨어는 풍부한 종속성 관리 언어, 소켓 활성화, 타이머, 네트워크 및 스토리지 관리 등과 같은 많은 기능을 제공하는 SystemD입니다. AFAIK, 임베디드 Linux 운영 체제에서는 이는 덜 일반적이며 임베디드 시스템은 아마도 실패한 서비스를 다시 시작하는 데 그다지 좋지 않은 클래식 SysV를 사용할 것입니다(또는 전혀 수행하지 않는 경우가 많습니다. 해당 작업은 " 서비스 "스크립트"를 사용하며 대부분의 구현은 어떤 종류의 재시작도 수행하지 않습니다.) SysV 기반 운영 체제의 경우 많은 관리자는 SysV 서비스 프레임워크를 사용하여 다른 서비스 관리자(예: Supervisord 또는 Runit)를 시작하고 서비스를 관리하도록 하는 것을 선호합니다. .