추가 읽기

추가 읽기

systemd포크된 서비스를 기반으로 한 시작 스크립트가 있습니다 .fooYAJSW(또 다른 Java 서비스 래퍼). 문서의 관련 부분은 .service다음과 같습니다.

ExecStart=/opt/foo/startup.sh
ExecStop=/opt/foo/shutdown.sh
Restart=always    
Type=forking
PIDFile=/opt/foo/wrapper.pid

startup.sh스크립트는 YAJSW 래퍼 시작을 담당합니다. 시작 중에 해당 PID가 파일에 기록되도록 YAJSW 구성 파일을 설정합니다.

 wrapper.pidfile = /opt/foo/wrapper.pid

이렇게 하면 (어떤 이유로든) 래퍼 프로세스가 종료되면 systemd가 이를 시작해야 하며 이는 원하는 동작입니다. 이 구성이 제대로 작동하는지 확인했지만 Journalctl에 이상한 줄이 표시됩니다.

foo.service: PID file /opt/foo/wrapper.pid not readable (yet?) after start: No such file or directory

이상하게도 systemctl status foo는 마스터 PID를 올바르게 표시합니다.

foo.service
...
Main PID: 12313 (java)

제가 뭔가 잘못하고 있는 건가요, 아니면 소프트웨어 구성 요소 중 하나의 버그인가요? 저는 Ubuntu 16.04.3 LTS, 커널 버전 4.4.0, 시스템 버전 229.4를 실행하고 있습니다. 어떤 도움이라도 대단히 감사하겠습니다.

답변1

포크된 서비스 [...] YAJSW(또 다른 Java 서비스 래퍼) [...] ExecStart=/opt/foo/startup.sh[...] ExecStop=/opt/foo/shutdown.sh[...] PID가 파일에 기록됩니다 [...]

이런 종류의 작업은 Java에서 흔히 볼 수 있으며 일반적으로 Oracle 시스템에서도 흔히 볼 수 있는 것처럼 보이지만 전혀 필요하지 않습니다. 실제 서비스 관리자에서 실행하기 위해 쉘 스크립트나 Java로 작성된 Poor Man Service Manager가 필요하지 않습니다. PID 파일은 완전히 위험하고 불안정한 메커니즘입니다. startup.sh스크립트가 필요하지 않으며 shutdown.sh결국 좋은 결과 없이 프로세스 트리 위로 실제 서비스 프로세스를 밀어올리게 됩니다. 추가 YAJSW 구성 파일이 필요하지 않습니다. 메모리의 표준 출력 버퍼링을 기반으로 하는 복잡하고 특별한 로깅 메커니즘이 필요하지 않습니다.

귀하의 서비스 프로세스는 실제 서비스 관리에 의해 직접 관리되어야 하며 거의 아무것도 없기 때문에 시스템화된 포크 준비 프로토콜을 사용하지 않습니다.실제로그걸 써. Poor Man's Service Manager를 실행하기 위해 래퍼 쉘 스크립트를 사용하지 마십시오. PID 파일을 사용하지 마십시오. 모든 셸 스크립트 래퍼는 포크가 아닌 체인로드되어야 합니다. 구성 파일은 일부가 아닌 시스템 서비스 단위 파일입니다.다른구성 파일. 로깅 메커니즘은 표준 출력 및 표준 오류를 캡처하고 해당 데이터를 파일에 기록하는 서비스 관리와 함께 제공되는 메커니즘입니다.

추가 읽기

답변2

나는 이것이 버그라기보다는 복잡성 문제라고 말하고 싶습니다. 현재 애플리케이션을 시작하고 관리하기 위한 체인이 있습니다.

systemd -> startup.sh -> YAJSW -> actual app

나는 start.sh와 YAJSW가 정확히 무엇을 하는지는 모르지만 관리를 단순화하는 것이 더 나을 것입니다.

systemd -> actual app

그래서 관리에 문제가 있으면많은무슨 일이 일어났는지 추론하는 것이 더 쉽습니다.

관리 도구 의 사용을 극대화 systemd하고 스크립트와 YAJSW가 수행하는 작업을 최소화하거나 제거하여 상황을 단순화하는 것이 좋습니다.

관련 정보