저는 몇 달 동안 systemd 타이머를 안정적으로 사용해 왔지만 최근에 트리거된 서비스 작업이 아직 실행되지 않았다는 경고를 받았습니다. 을 사용하면 systemctl list-timers실제로 더 이상 예약된 트리거 이벤트가 표시되지 않습니다.
우연이라고 생각하고 타이머를 다시 시작하고 사용하여 list-timers이제 다음 실행이 예상대로 예정되어 있음을 발견했습니다. 그러나 이제 타이머는 한 번만 실행된 다음 시간이 다시 시작될 때까지 새 이벤트 예약을 중지합니다.
Ubuntu 18.04나는 이것이 시스템 버그일지도 모른다고 생각하여 호스트를 에서 로 업그레이드했지만 Ubuntu 20.04문제가 지속됩니다.시스템 타이머가 새 이벤트 전달을 중지하는 원인은 무엇입니까?.
트리거된 서비스가 24시간 이상 중단되고 실행되는지 확인했는데 약 8시간 만에 안정적으로 완료됩니다.
이것은 타이머 장치입니다:
[Unit]
Description=Runs service
[Timer]
Unit=myservice.service
# Run every day at this time.
OnCalendar=*-*-* 10:00:00
[Install]
WantedBy=timers.target
.service완료하는 데 약 8시간이 걸리는 일부 유지 관리 작업을 수행하는 파일은 다음과 같습니다 .
[Unit]
Description=Do things
# Send email if this fails
OnFailure=status-email-devops@%n.service
[Service]
Environment="[email protected]"
User=example
Group=example
UMask=002
ExecStart=do-thing
ExecStartPost=/usr/local/bin/aws cloudwatch put-metric-data --region us-east-1 --namespace Example --dimensions Host=%H --metric-name example --value 1
StandardOutput=journal
이는 systemd v245의 경우입니다.
답변1
가능한 원인을 찾았습니다. 타이머가 실행 중인 서비스에 무한 루프로 변하는 버그가 있었습니다. 시스템 타이머는 일반적으로 서비스의 두 번째 인스턴스를 호출하지 않으므로(이미 실행 중인 서비스가 있는 경우) 타이머가 새 이벤트 예약을 중지한 것으로 보입니다.
내가 얻은 한 가지 단서는 정지된 타이머와 새로 시작된 타이머를 비교하는 것이었습니다. systemctl show foo.timer상태에 대한 자세한 내용을 확인하기 위해 타이머를 사용하여 다음을 확인했습니다.
SubState=running
새로 시작된 타이머가 그 자리를 대신합니다 SubState=waiting.
이 시점에서 나는 내가 해야 할 일을 했습니다. 그것은 systemctl status대상 서비스에서 사용하는 것이었습니다. 물론 마지막 시간부터 계속 실행 중임을 보여 타이머가 다시 실행되는 것을 방지했습니다.