app서버에 애플리케이션이 설치되어 있고 이 애플리케이션이 이라는 애플리케이션 제어를 제공한다고 가정합니다 appctl. 관리자로서 다음을 통해 애플리케이션을 시작/중지/다시 시작할 수 있습니다 appctl.
appctl start
appctl stop
appctl restart
그런 다음 다음을 사용하여 이 작업을 수행해야 한다는 것을 깨달았으므로 systemctl하나를 작성 app.service하고 /etc/systemd/system데몬을 다시 로드한 후 다음을 사용하여 애플리케이션을 시작/중지/다시 시작할 수 있습니다 systemctl.
systemctl start app.service
systemctl stop app.service
systemctl restart app.service
이제 내 문제가 발생합니다. 다음을 사용하여 응용 프로그램을 중지한 appctl restart후systemctl status app.service1시간 전부터 비활성(죽음). 이는 애플리케이션의 실제 상태를 반영하지 않습니다. 받아 들일 수 있습니까?
개인적으로는 다시 시작한 적이 없기 때문에 정상적인 느낌입니다 systemctl. 하지만 문서 인용, systemctl내부 메커니즘 분석 과 같은 더 많은 주장을 원합니다 .
답변1
맞아요, 예상된 결과입니다. 나는 appctl이런 일이 일어나는 것을 막을 수 있을 것이라고 기대하지 않습니다 . 그러나 올바른 사용을 장려하는 방법을 고려해 볼 가치가 있습니다.
시스템 관리자는 이를 직접 사용해서는 안 된다는 점을 알려야 할 수도 있습니다 appctl start/restart. 서비스 상태가 "애플리케이션의 실제 상태를 반영하지 않는다"는 것만이 아닙니다. systemd를 우회하여 데몬이 appctl start실행하는 모든 셸에서 다양한 속성을 상속 한다는 사실과 같은 이점을 잃었습니다 . 그리고 systemctl stop app.service작동하지 않습니다 :). 또한 ExecStop=시스템이 종료되면 사용자 정의 종료 처리(예:)가 실행되지 않습니다.
systemd의 자체 데몬은 /usr/bin 또는 /usr/sbin이 아닌 /usr/lib의 하위 디렉터리에 설치하여 이를 권장합니다. systemd-udevd예를 들어 사용자의 PATH에는 없습니다. /usr/libexec/(하위 디렉토리 여부)는 동일한 작업에 사용될 수 있습니다. 기술적으로는 System V 스타일의 initscript를 제공하더라도 동일한 작업을 수행할 수 있습니다...
그러나 예를 들어 복잡한 구성이 있고 터미널에서 오류 메시지를 받으려는 경우 데몬에 대한 편리한 액세스를 제공하는 매개변수가 있습니다. 예는 다음과 같습니다 apache -t.
시작/다시 시작/중지(시스템 서비스는 ExecReload도 정의할 수 있음) 및 시작/다시 시작/중지 이외의 동사 가 있는 경우 reload이를 분리할 수 있습니다. 예를 들어 기본 데몬 바이너리를 사용하여 이 네 가지를 구현하고 다른 것을 appctl.
appd시스템 관리자는 경로에 있더라도 직접 실행하면 상당한 단점이 있다는 점을 이미 이해하고 있어야 하지만 appctl터미널에서 실행하는 것은 괜찮습니다.