私は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に移動しました。
私のスクリプトがrootの代わりに通常のユーザーによって実行されるように、各サービスファイルに "User ="セクションを追加しました。
システムの起動時にタイマーが実行されず、SSHを介してログインしたときに時々タイマーが実行されるという問題もあります。この問題は現在、root アカウントによって制御されるため、解決されていますが、私のスクリプトを実行すると、まだファイルの所有権属性を保持する一般ユーザーの 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
現在開始されているログに無効なタイムスタンプがあることを確認してください。他の人の質問が私の質問と一致する場合に備えて、これを追加します。