systemctl은 systemd의 LGPL 라이센스를 따르는 시스템 자원 통합 관리 도구이다 설정 파일은 /etc/systemd 아래에 위치하며, 각 파일 별로 [Unit], [Service], [Install]로 구성됨 - systemd 는 리눅스 커널 API 로 설계된 시스템 관리 데몬이다. - Lennart Poettering 와 Kay Sievers 가 처음 개발 하였다. (GNU 약소 GPL 라이선스) - 시스템이 부팅하는 동안 데몬 스크립트를 병렬로 수행 할수 있도록 설계하였다. 병렬로 서비스를 수행하기 때문에 서비스간의 종속성 및 실행 순서 관리가 매우 중요하다. - 프로세스간의 통신은 D-bus 에서 담당한다. (소켓, D-bus 지원) - 전통적인 Sysvinit 의 경우 서비스 감시 기능이 부족하다는 단점이 있다. - 전통적인 Sysvinit 의 경우 서비스간 종속성을 관리하지 못한다. - 전통적인 Sysvinit 의 경우 볶잡한 스크립트를 필요로 한다. (start, status, stop 등 각각에 대한 스크립팅이 필요하다.) -> 이건 확실히 그렇습니다. 데몬 관리가 어려움... - 전통적인 Sysvinit 의 경우 udev 관리 면에서 부적당하다. - systemd 서비스 등록 샘플 [Unit] Description=Sample Service Requires=local-fs.target After=local-fs.target [Service] Type=simple PIDFile=/var/run/sample.pid ExecStart=/usr/sbin/sampled -d ExecStop=/usr/sbin/sampled -k [Install] WantedBy=multi-user.target === [Unit] 섹션 === Description= 해당 유닛에 대한 상세한 설명을 포함한다. Requires= 상위 의존성을 구성한다. 목록의 유닛이 정상적일 경우 유닛이 시작된다. (필요 조건) RequiresOverridable...
웹사이트 개발을 완료하고 서비스할 프로덕션(production) 서버에 배치(deploy)할 때 고민하게 되는 문제 중 하나가 서버에서 띄워야 하는 여러 가지 프로세스들을 어떻게 띄울 것인가 하는 문제다. 프로세스가 죽으면 다시 띄우는 것도 물론 필요하다. monit 이나 supervisord , god 등은 이런 목적으로 나온 것이다(몇 가지 부가적인 목적이 더 있긴 하다). 하지만 이건 OS에 대한 이해 부족에서 나온 것이다. 프로세스 관리는 OS의 핵심적인 기반이 되는 기능이다. 본 연구에서는 왜 monit 등이 잘못된 선택인지, 올바른 방법은 무엇인지에 대해 다룰 것이다. 프로세스 No. 1 Init 올바른 방법은 OS의 init 시스템, 혹은 그와 유사한 대안 시스템을 사용하는 것이다. init은 유닉스에서 부팅될 때 첫번째로 만들어지는 프로세스다. 그래서 프로세스 번호가 1이고, 이후의 모든 프로세스는 init 프로세스의 자손이 되고, 시스템이 부팅될 때 뜨는 모든 프로세스는 init이 띄우게 된다. respawn이 설정된 프로세스는 죽었을 때 다시 띄우는 역할도 한다. 그러니 서버에 프로세스를 띄워야 한다면 init에 맡기는 것이 자연스럽지 않겠는가. 물론 init 시스템은 낡고 문제점이 있지만, 그건 부팅 과정의 문제점이 크고, 프로세스를 관리하는 데는 별 문제가 없다. 다만, 조금 번거롭긴 하다. 사용법은 Managing Linux daemons with init scripts 를 참조하라. 보면 알겠지만 좀 귀찮다. 하지만, 이제 이 init 시스템은 역사 속으로 사라질 예정이다. 아니, 많은 리눅스 배포판에서 이미 사라졌다. 우분투는 이미 수년 전 init을 upstart 로 대체했고, 다른 배포판들은 systemd 로 방향을 잡았으며 최근에 우분투도 systemd에 합류하기로 했다. 그러니까, 미래는 systemd에...
댓글
댓글 쓰기