cronが実行されないときの確認方法｜crontab・ログ・権限を順番に調べる
Linuxサーバーで定期的な処理を自動実行したいとき、「cron」という仕組みがよく使われます。
バックアップやログ整理、データの取得、スクリプトの実行などをcrontabに登録しておけば、指定した時間に自動で処理できます。
ところが、設定したはずのcronが実行されず、
「crontabには登録されているのに動かない」
「手動では動くのにcronから実行すると失敗する」
といった問題が起こることがあります。
このような場合は、crontabだけを確認するのではなく、cronサービス、実行ユーザー、権限、PATH、ログなどを順番に確認することが重要です。
ここでは、cronが実行されないときに、どこから確認すればよいのかをLinuxサーバー初心者向けに整理します。
cronが実行される仕組みとは？
cronは、指定した時間にコマンドやスクリプトを自動実行するための仕組みです。
例えば、
0 3 * * * /home/user/backup.sh
と設定すると、毎日午前3時にbackup.shを実行する設定になります。
cronでは、次のような処理を自動化できます。
- データベースのバックアップ
- ログファイルの整理
- ファイルの削除
- 定期的なスクリプト実行
- データの取得
- サーバーのメンテナンス
crontabには実行する時間とコマンドを登録し、cronがその設定を確認して処理を実行します。ユーザーごとにcrontabを持つことができ、通常はそのcrontabを所有するユーザーとしてコマンドが実行されます。(man7.org)
cronが実行されないときに最初に確認すること
cronが動かないときは、いきなり設定を変更するのではなく、次の順番で確認すると原因を切り分けやすくなります。
- crontabにジョブが登録されているか
- cronサービスが動いているか
- cronのログに実行記録があるか
- 実行ユーザーが正しいか
- スクリプトやコマンドに権限があるか
- PATHや環境変数に問題がないか
- スクリプトを手動で実行すると動くか
- サーバーの時刻やタイムゾーンが合っているか
特に重要なのは、cronそのものが動いていないのか、それともcronは動いているものの、実行したコマンドが失敗しているのかを分けることです。
crontabにジョブが登録されているか確認する
まず、現在のユーザーに登録されているcronを確認します。
crontab -l
登録した内容が表示されれば、そのユーザーのcrontabにはジョブが登録されています。
何も表示されない場合は、そもそもジョブが登録されていない可能性があります。
crontabを編集するときは、
crontab -e
を使います。
例えば、テストとして毎分スクリプトを実行するなら、
* * * * * /home/user/test.sh
のように設定できます。
cronの設定では、一般的に、
分 時 日 月 曜日 コマンド
という順番で指定します。
例えば、
0 3 * * * /home/user/backup.sh
なら、毎日午前3時に実行します。
crontabはユーザーごとに管理されるため、別のユーザーのcrontabを確認していると、登録したはずのジョブが見つからないことがあります。(man7.org)
rootのcrontabも確認する
rootとしてcronを登録している場合は、通常の、
crontab -l
ではなく、
sudo crontab -l
で確認します。
例えば、
crontab -e
と、
sudo crontab -e
は同じcrontabを編集しているわけではありません。
実行するユーザーも変わるため、どのユーザーに登録したcronなのかを確認することが重要です。
cronの設定を調べるときは、
whoami
で現在のユーザーを確認しておくと分かりやすくなります。
cronサービスが動いているか確認する
crontabに正しく登録されていても、cronサービスが動作していなければジョブは実行されません。
UbuntuやDebian系の環境では、
systemctl status cron
で状態を確認できます。
正常に動作していれば、
Active: active (running)
などの表示を確認できます。
サービスが停止している場合は、
sudo systemctl start cron
で起動できます。
ただし、cronが実行されない原因を調べている段階では、すぐに再起動するよりも、まず現在の状態やログを確認したほうが原因を特定しやすくなります。
Linuxの種類によってはサービス名がcrondになっている場合もあります。
その場合は、
systemctl status crond
を確認します。
cronのログを確認する
次に確認したいのがcronのログです。
cronがジョブを実行した記録が残っていれば、少なくともcronがスケジュールを認識していることを確認できます。
systemdのjournalを利用している環境では、
journalctl -u cron
でcron関連のログを確認できます。
直近のログだけを確認するなら、
journalctl -u cron --since "1 hour ago"
のように指定できます。
journalctlはsystemdのjournalに保存されたログを検索するためのコマンドです。(Ubuntu Manpage)
環境によっては、syslogにcronの記録が保存されていることもあります。
例えば、
grep CRON /var/log/syslog
で確認できます。
ただし、ログの保存場所はLinuxのディストリビューションや設定によって異なるため、/var/log/syslogに必ず存在するとは限りません。
cronのログに実行記録がある場合
ログを確認して、対象のcronが実行された記録がある場合は、cronサービス自体は動いている可能性があります。
例えば、
CRON[1234]: (user) CMD (/home/user/test.sh)
のような記録が確認できれば、cronがコマンドを起動していることが分かります。
この場合は、
cronの設定そのものよりも、実行したスクリプトやコマンド側に原因がある可能性があります。
ここからは、スクリプトの権限やPATH、環境変数などを確認していきます。
スクリプトの実行権限を確認する
cronからシェルスクリプトを実行している場合は、ファイルの権限を確認します。
ls -l /home/user/test.sh
例えば、
-rwxr-xr-x
のようにxが付いていれば実行権限があります。
実行権限がない場合は、
chmod +x /home/user/test.sh
で追加できます。
ただし、権限を変更すれば必ず解決するとは限りません。
cronではスクリプトを実行するユーザーも重要です。
cronの実行ユーザーを確認する
cronは、登録したcrontabの所有者を基準にコマンドを実行します。(man7.org)
例えば、一般ユーザーのcrontabに登録した場合、そのユーザーの権限で実行されます。
そのため、ターミナルでrootとして実行した場合には成功するのに、cronでは失敗することがあります。
例えば、
sudo /home/user/test.sh
では動くのに、
crontab -e
で登録したcronでは動かない場合です。
このようなときは、ファイルやディレクトリの所有者・権限を確認します。
ls -l /home/user/test.sh
ディレクトリなら、
ls -ld /home/user
などで確認できます。
「rootなら動く」という状態は、権限の問題を切り分けるための手がかりになります。
手動で実行すると動くか確認する
cronのトラブルでは、登録しているコマンドを手動で実行してみることも重要です。
例えば、
/home/user/test.sh
を実行します。
ここでエラーが表示されるなら、cronではなくスクリプト自体に問題がある可能性があります。
例えば、
Permission denied
なら権限、
command not found
ならコマンドのPATH、
No such file or directory
ならファイルやパスなどを確認します。
一方、手動実行では正常なのにcronからだけ失敗する場合は、cronの実行環境を確認します。
cronではPATHが違うことがある
「ターミナルでは動くのにcronでは動かない」という問題では、PATHが原因になることがあります。
例えば、ターミナルでは、
python3 /home/user/script.py
で動くとします。
しかしcronから実行すると、
python3: command not found
になる場合があります。
このような場合は、コマンドの場所を確認します。
which python3
例えば、
/usr/bin/python3
と表示されたなら、cronでは、
/usr/bin/python3 /home/user/script.py
のように絶対パスで指定できます。
cronでは通常のログインシェルと同じ環境がそのまま使われるとは限らないため、サーバー上の自動処理では必要なコマンドを絶対パスで指定する方法がトラブル防止につながります。
cron実行時にはHOMEやSHELLなどの環境が設定されますが、普段のターミナル環境と完全に同じとは考えないほうが安全です。(man7.org)
環境変数が原因になることもある
PATH以外の環境変数も、cronが動かない原因になることがあります。
例えば、スクリプトが、
DATABASE_URL
APP_ENV
HOME
PATH
などの環境変数を利用している場合です。
ターミナルでは環境変数が設定されていても、cronから実行したときには期待した値が存在しない可能性があります。
そのため、
echo $PATH
などで普段の環境を確認するだけでなく、cronから実行した場合の環境も必要に応じて確認します。
重要な設定値がある場合は、スクリプトや設定ファイル側で明示的に指定する方法もあります。
ただし、APIキーやパスワードなどの機密情報をcrontabに直接書く場合は注意が必要です。
cronの実行結果をログに保存する
cronから実際に何が起きているのか分からない場合は、一時的に標準出力とエラー出力をファイルに保存する方法もあります。
例えば、
* * * * * /home/user/test.sh >> /tmp/cron-test.log 2>&1
とします。
これでスクリプトの出力を、
/tmp/cron-test.log
に保存できます。
しばらく待ってから、
cat /tmp/cron-test.log
を確認します。
エラーが出ていれば、スクリプト側の問題をさらに調べることができます。
テストが終わったら、不要なログ出力は削除してください。
ログを長期間残すと、ディスク容量を消費する可能性があります。
cronの時間設定を確認する
設定そのものが正しくても、指定した時間を勘違いしているケースがあります。
crontabでは、
分 時 日 月 曜日
の順番で指定します。
例えば、
0 3 * * *
は毎日3時です。
一方、
30 3 * * *
なら毎日3時30分になります。
「3時間ごと」のような指定と、「毎日3時」の指定を混同すると、期待したタイミングで実行されません。
まずはテストとして、
* * * * * /home/user/test.sh
のように毎分実行して動作を確認し、その後に本来のスケジュールへ戻す方法もあります。
サーバーの時刻とタイムゾーンを確認する
cronが設定した時間に実行されない場合は、サーバーの時刻も確認します。
現在の時刻は、
date
で確認できます。
タイムゾーンなどを確認するなら、
timedatectl
を使用します。
例えば、自分が日本時間を基準に設定していても、サーバー側の時刻設定が異なれば、想定した時間と実際の実行時間がずれることがあります。
VPSやクラウドサーバーでは、ローカルPCとサーバーの時刻設定が同じとは限らないため、cronの時間が合わない場合は一度確認しておくと安心です。
/etc/crontabとユーザーのcrontabは書式が違う
cronには、ユーザーがcrontab -eで管理するものだけでなく、
/etc/crontab
/etc/cron.d/
などで管理されるシステム側のcronもあります。
ユーザーのcrontabでは、
* * * * * /home/user/test.sh
のように指定します。
一方、/etc/crontabや/etc/cron.d/では、実行ユーザーを指定する形式があります。
* * * * * root /home/user/test.sh
この違いを知らずに設定すると、正しいと思っているのに実行されない原因になることがあります。
そのため、どの場所のcronを編集しているのかを最初に確認することが大切です。
Ubuntuのマニュアルでも、ユーザーcrontabと/etc/crontab・/etc/cron.d/では書式が異なることが説明されています。(Ubuntu Manpage)
cronが実行されないときの確認順序
ここまでの内容を整理すると、次の順番で確認すると原因を切り分けやすくなります。
| 確認する項目 | コマンド例 | 主な確認内容 |
|---|---|---|
| crontab | crontab -l | ジョブが登録されているか |
| rootのcrontab | sudo crontab -l | root側に登録していないか |
| cronサービス | systemctl status cron | cronが動作しているか |
| ログ | journalctl -u cron | ジョブの実行記録があるか |
| 権限 | ls -l | 実行ユーザーに権限があるか |
| 手動実行 | /path/to/script.sh | スクリプト自体が動くか |
| PATH | which command | コマンドの場所を確認 |
| 時刻 | date | サーバー時刻を確認 |
| タイムゾーン | timedatectl | 時刻設定を確認 |
最初からすべての設定を変更するのではなく、どの段階で処理が止まっているのかを確認することがポイントです。
cronを直すときに注意したいこと
cronが実行されないからといって、すぐにサーバーを再起動する必要はありません。
まず、
crontab -l
で設定を確認し、
systemctl status cron
でサービスを確認します。
その後、
journalctl -u cron
でログを確認し、登録しているスクリプトを手動で実行します。
また、権限の問題を解決するために、
chmod 777
のようにファイルやディレクトリの権限を無制限に広げる方法は避けたほうが安全です。
必要なユーザーだけがアクセスできるように、所有者やグループ、権限を確認しながら修正してください。
cronの問題だけを調べているつもりでも、ログやバックアップ処理が原因でディスク容量が増えているケースもあります。
サーバーのディスク容量が不足している場合は、**「Linuxのディスク容量が足りないときの確認方法」**もあわせて確認すると、別の原因を切り分けやすくなります。
まとめ
cronが実行されないときは、crontabの設定だけを確認して終わりにするのではなく、crontab・cronサービス・ログ・実行ユーザー・権限・PATH・スクリプトを順番に確認することが重要です。
特に、
crontab -l
systemctl status cron
journalctl -u cron
の3つは、最初に確認したい基本的なコマンドです。
手動では動くのにcronから動かない場合は、PATHや環境変数、実行ユーザー、ファイルへのアクセス権など、cronと通常のターミナルとの環境の違いを確認します。
原因が分からないまま設定を変更したりサーバーを再起動したりするのではなく、どの段階で処理が止まっているのかを一つずつ確認すると、cronのトラブルを切り分けやすくなります。
cronが実行されないときによくある質問
cronが動いているか確認するにはどうすればいいですか？
まず、
systemctl status cron
でcronサービスの状態を確認します。
その後、
journalctl -u cron
で実行記録を確認すると、cronがジョブを処理しているかを調べやすくなります。
crontab -lに登録した設定が表示されません
別のユーザーのcrontabを確認している可能性があります。
一般ユーザーなら、
crontab -l
rootなら、
sudo crontab -l
を確認してください。
crontabはユーザーごとに管理されるため、登録したユーザーを確認することが重要です。(man7.org)
手動では動くのにcronでは動きません
PATHや環境変数、実行ユーザー、ファイルの権限などが原因になっている可能性があります。
特にコマンドは、
/usr/bin/python3
のように絶対パスを指定すると、PATHによるトラブルを避けやすくなります。
cronのログはどこで確認できますか？
環境によって異なります。
systemdのjournalを利用している場合は、
journalctl -u cron
を確認できます。
Ubuntuなどでは/var/log/syslogにcronの記録が保存されている環境もあります。