Systemd는 실패한 서비스 다시 시작을 지연하고 30개의 절전 시간을 추가하는 것으로 보입니다.

Question

귀하 의 서비스 에는 Type=forking. 서비스가 실행되는 동안 존재합니다 . 완료 되면 생성된 프로세스( )가 선택되어 이 상태로 들어갑니다.ExecStart=fork()activating (start)ExecStart=ExecStart=systemdMainPIDactive (running)

귀하의 ExecStart=프로그램은 bash 스크립트인 것 같습니다. 스크립트는 다음과 같습니다.

#!/bin/bash
sudo -u admin -i python /path/to/application/myapplication.py start p1 | logger &

while /bin/true; do
    sleep 30
done

스크립트에 몇 가지 문제가 있지만 관심을 가질 부분은 sleep 30마지막 부분입니다. 기본 프로세스가 실행 중이지만 systemd는 active (running)완료될 때까지 해당 상태로 들어가지 않습니다 sleep 30. 새 PID가 sleep 30계속 호출되므로 매번 새 PID가 표시됩니다 .

잘 작동하는 스크립트는 애플리케이션을 생성한 후 즉시 종료됩니다. 스크립트는 애플리케이션이 종료되기 전에 올바르게 시작되었다는 피드백을 기다리고 있을 수 있습니다. 이는 괜찮지만, 기다리고 있는 피드백을 확실히 얻지 못하고 있으므로 그렇지 않은 이유를 알아내기 위해 더 깊이 파고들어야 합니다.

그러나 내 생각에는 스크립트가 응용 프로그램이 종료되기 전에 종료되기를 기다리고 있을 가능성이 더 높습니다. 이 같은:

python myapplication.py &
PID=$!

while ps | grep -q $PID; do
    sleep 30
done

대본 이 아닌 당신 kill이 하고 있는 것처럼 들리기 때문인 것 같아요 . 이는 장치가 완료될 때까지 그대로 유지된다는 의미입니다 . 그런 다음 스크립트가 중지되기 전에 Python 애플리케이션의 PID가 여전히 존재하는지(존재하지 않는지) 확인합니다.pythonExecStart=activating (start)sleep 30

나를 괴롭히는 또 다른 스크립트 부분은 대화형 사용자를 인증하기 위한 sudo것 sudo입니다. 스크립트의 유효성을 검사하기 위한 것이 아닙니다. 대신, 더 우아한 솔루션은 User=admin서비스 내에서 이를 사용하는 것입니다.

두 가지 해결책이 있습니다. 옵션 2는 내가 가장 좋아하는 것입니다.

루프를 편집 /path/to/application/myapplication하고 삭제합니다 while.
간단한 서비스를 사용하고 스크립트를 완전히 건너뛰세요. 이는 다른 초기화 시스템(현재는 필요하지 않은 자체 로거를 명시적으로 시작함)을 위해 작성된 다음 셸에서 호출될 때 차단되도록 수정된 것처럼 보입니다. systemd이 모든 작업은 귀하를 위해 수행되었으므로 스크립트가 전혀 필요하지 않을 것입니다.

[Unit]
Description=my application service for %i.

[Service]
Type=simple
ExecStart=/usr/bin/python3 /path/to/application/myapplication.py %i
User=admin
Restart=always

[Install]
WantedBy=multi-user.target

도움이 되지 않으면 게시해 주세요./path/to/application/myapplication

Answer 1