저는 crontab을 systemd의 타이머 장치로 마이그레이션했습니다. 그것들은 모두 다음과 유사해 보입니다:
.타이머 파일:
[Unit]
Description=timer that uses myjob.service
[Timer]
OnCalendar=*-*-* *:00:00
Unit=myjob.service
[Install]
WantedBy=timers.target
.서비스 파일:
[Unit]
Description=Script that runs myjob.sh
[Service]
ExecStart=/home/user/myjob.sh
내 타이머는 작동하지만 시스템을 다시 시작할 때도 실행됩니다. OnCalendar 이벤트가 컴퓨터를 다시 시작할 때가 아니라 지정된 시간에만 실행되기를 원합니다. 어떤 아이디어가 있나요?
업데이트: "사용자" 타이머를 루트/시스템 타이머로 변환하여 이 문제를 해결했습니다.
모든 .service 및 .timer 파일을 비활성화하고 해당 파일을 홈 디렉터리에서 /etc/systemd/system으로 옮겼습니다.
내 스크립트가 루트 대신 일반 사용자에 의해 실행되도록 각 서비스 파일에 "User=" 섹션을 추가했습니다.
이제 시스템 시작 시 타이머가 실행되지 않고 SSH를 통해 로그인할 때 가끔 타이머가 실행되는 문제도 있습니다. 이 문제는 이제 루트 계정에 의해 제어되므로 해결되었지만 내 스크립트를 실행하면 여전히 내 파일의 소유권 속성을 유지하는 일반 사용자의 PID로 실행됩니다. 문제가 해결되었습니다.
답변1
나는 같은 문제가 있었고 Persistent
.timer 파일의 설정에 관계없이 장치가 항상 시작 시 실행되는 이유를 알 수 없었습니다. 시간이 좀 걸렸지만 마침내 이유를 찾았습니다(@alexander - 올바른 방향을 알려줬습니다) Tolkachev의 의견).
문제는 내가 항상 WantedBy=basic.target
.service 파일의 [Install] 섹션에 이와 같은 내용을 포함한다는 것입니다(표준 시스템 서비스 복제 스파게티의 일부이기 때문입니다). 이는 실제로 basic.target이 시작될 때(시스템 시작이라고도 함) 장치가 시작되도록 하는 것으로 나타났습니다.
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#WantedBy= https://www.freedesktop.org/software/systemd/man/systemd.special.html#basic.target
나는 OP가 이전 .service를 비활성화하고( .service에 의해 생성된 심볼릭 링크를 삭제하려면 이 작업을 수행해야 함 WantedBy
) 이를 다시 작성하거나 실행하지 않을 때 [Install] 섹션을 무시함으로써 실수로 문제를 해결했다고 의심합니다 systemctl enable
.
너무 오래;.service 파일의 [Install] 섹션이 .timer 파일에 의해 트리거되는 것을 원하지 않습니다.
답변2
다른 답변에서 다루지 않은 더 많은 가능성이 있습니다 ...
가능성 A
재부팅 시 서비스를 시작하는 것은 타이머가 아니라 systemctl enable <service-unit>
이전 어느 시점에 설치/활성화(즉, 통과)된 서비스 자체일 수 있습니다.
[Install]
예를 들어 서비스 단위에 섹션이 있고 과거 어느 시점에 서비스를 활성화했기 때문에 서비스가 시작됩니다 .
가능성 B
서비스는 다른 단위의 종속성으로 선언되었기 때문에 실행될 수 있습니다.
타이머 실행을 포함하는 cron to systemd 타이머에 대한 상위 검색 결과 블로그 게시물이 있습니다 Requires=myUnit.service
. 부팅 시 타이머가 시작될 때(필요한 대로)... 타이머에 서비스(종속성)가 필요하기 때문에 서비스는 부팅 전에 타이머에 있습니다. .. 즉, 부팅할 때마다.
가서 확인해보세요...
- 재시작,
- 재부팅 시 서비스가 실행되었나요?
systemctl status <service-unit>
- 그렇지 않다면 문제 없습니다.
- 시작 시 서비스를 실행하는 타이머인가요? :
systemctl list-timers
- 서비스의 타이머를 확인하세요. 방금 실행/트리거되었나요?
- 그렇다면 타이머가 서비스 실행을 트리거합니다.
- 타이머 장치의 설정을 확인하십시오
Persistent
. 타이머가 실행을 놓친 것으로 판단하여 실행 중일 수 있습니다.
- 타이머 장치의 설정을 확인하십시오
- 그렇지 않은 경우:
- 타이머 장치가 귀하의 서비스(
Requires=<service-unit>
또는 그와 유사한 어리석은 것) 에 의존하지 않는지 확인하십시오. grep -R <service-unit> /etc/systemd/system/
다른 장치가 귀하의 서비스를 참조하는지 또는 의존하는지 확인할 수 있습니다 .- 타이머(및 기타 장치)가 서비스에 의존하지 않는 경우...이전 설치/활성화로 인해 서비스가 실행 중일 수 있습니다.
- 타이머 장치가 귀하의 서비스(
- 달리기
systemctl is-enabled <service-unit>
. 이 메시지가 표시되면static
활성화되지 않았으며[Install]
섹션이 없음(양호)을 의미합니다.find /etc/systemd/system/*.wants -name '<service-name>*'
바보는 이전 설치/활성화에서 서비스를 시작하기 위해 남은 심볼릭 링크가 없는지 실행하고 확인하여 이를 확인했습니다 .
- 어떤 이유로 서비스가 활성화된 경우...
- 달리기
systemctl disable <service-unit>
[Install]
서비스 장치에서 섹션을 제거하십시오.- 실행
systemctl --system daemon-reload
하여 변경 사항을 로드합니다. - 다시 시작하고 서비스가 시작 시 더 이상 실행되지 않는지 확인합니다.
- 달리기
타이머를 cron 대체품으로 사용하기 위한 팁...
- 타이머가 작동하는 것을 원하지 않습니다
Requires=
. Wants=
당신은 당신의 서비스 나Requires=
(기다리는) 당신의 타이머를 원하지 않습니다 .[Install]
시작 시 타이머의 나머지 부분과 함께 시작되도록 타이머 장치에 섹션을 포함 해야 합니다 .- 타이머를 활성화/시작하여 재부팅 후 타이머가 다시 실행되도록 하려고 합니다. (타이머가 실행 중이라고 해서 서비스가 실행 중이라는 의미는 아닙니다.)
enable
귀하는 귀하의 서비스가[Install]
귀하의 서비스 단위에 섹션을 갖는 것을 원하지 않으며 , 귀하도 마찬가지입니다.
[Install]
나는 사람들이 섹션 없이 그리고/또는 실행하지 않고 유닛 파일을 새로운 위치/이름에 다시 생성하기 때문에 여기에서 많은 "솔루션"이 작동한다고 생각합니다. systemctl enable <service-unit>
이것은 작동하지만 필수는 아닙니다. systemctl disable <service-unit>
원래 서비스 단위에서 실행하기 만 하면 다시 만들 필요가 없습니다.
답변3
~에 따르면문서기본적으로 잘못된 구성이므로 구성을 변경하거나 완전히 제거해야 합니다 Persistent=false
.Persistent
답변4
내 서버에서 이 문제를 조사하는 동안 다음을 발견했습니다.
$ systemctl status man-db.timer
Apr 09 08:10:00 anemone systemd[1]: man-db.timer: Not using persistent file timestamp Mon 2018-04-16 19:40:02 EDT as it is in the future.
Apr 09 08:10:00 anemone systemd[1]: Started Daily man-db cache update.
온보드 RTC의 배터리가 방전되어 시스템이 과거 날짜(아마도 파일 시스템에서 가져온 날짜)로 부팅된 것으로 나타났습니다. 실행하여 확인
journalctl --boot
현재 시작된 로그에 잘못된 타임스탬프가 있는지 확인하세요. 다른 사람의 질문이 내 질문과 일치할 경우를 대비하여 이것을 추가합니다.