crontabの@rebootはrootでのみ機能しますか？

man 5 crontab crontabを使用してブート時にスクリプトを実行する方法についてはかなり明確です。

   These special time specification "nicknames" are supported, which replace the 5 initial time and date
   fields, and are prefixed by the `@` character:
   @reboot    :    Run once after reboot.

そこで、幸いにもcrontabに（rootではなく、ユーザーアカウントの下に）1行追加しました。

@reboot     /home/me/myscript.sh

しかし、何らかの理由で、マシンの再起動時にmyscript.shが実行されません。（コマンドラインから呼び出すと正常に実行されるため、権限の問題ではありません）

私は何が欠けていますか？

@Anthonの質問に答えるための更新：

1. Oracle-linuxバージョン：5.8（uname：2.6.32-300.39.2.el5uek＃1 SMP）
2. cronバージョン：vixie-cron-4.1-81.el5.x86_64
3. はい、/home あるマウントされたパーティション。これが問題のようです。これを回避するにはどうすればよいですか？
4. 現在、myscript.shテキストメッセージのみをのファイルにエコーします/home/me。

cronにはさまざまな実装があるため、これは少しわかりにくいトピックになります。また、この機能を壊すいくつかのバグがあり、特にシャットダウン/ブートとリブートを行う場合、単に機能しないいくつかのユースケースもあります。

虫

データポイント＃1

Debianでのそのようなバグの1つは、「cron：@reboot jobs are not run」というタイトルでカバーされています。これにより、Ubuntuにも導入されたようです。直接確認することはできません。

データポイント＃2

Ubuntuのバグの証拠は、この@SOの Q＆A：@reboot cronjob not runningで確認できます。

抜粋

コメント＃1：.... 3）お使いのバージョンのcrondは@rebootをサポートしていない可能性があります。vixのcrondを使用していますか？... crontab -l -u userの結果を表示

コメント＃2：...特定のバージョンのcronの@rebootに依存する代わりに、initスクリプトとして設定することをお勧めします。

コメント＃3：... @MarkRobertsは再起動を削除し、1 * * * *を* / 1 * * * *に変更し、問題は解決しました！担当者マークをどこに送信すればよいですか？ありがとうございました！

そのQ＆Aで受け入れられた回答にもこのコメントがありました。

Lubuntuは@Reboot Cron構文をサポートしていません。

追加の証拠

データポイント＃3

追加の証拠として、誰かがまったく同じことを試み、それが機能しなかったことに不満を抱いているというこのスレッドがありました。タイトル：スレッド：Cron-@reboot jobs not working。

抜粋

Re：Cron-@rebootジョブが機能しない

見積もり当初の投稿ceallred投稿を見ますこれは私を殺しています...ラッパースクリプトを試してみました。手動で実行するとログファイルが生成されます...再起動しますが、ジョブは実行されず、ログファイルも作成されません。

Syslogは、CRONがジョブを実行したことを示しています...しかし、ここでも出力がなく、プロセスは実行されていません。7月15日20:07:45 RavenWing cron [1026]：（CRON）INFO（Running @reboot jobs）7月15 20:07:45 RavenWing CRON [1053]：（ceallred）CMD（/ home / ceallred / Scripts / run_spideroak。 sh> /home/ceallred/Scripts/SpiderOak.log 2>＆1＆）

cronは@rebootコマンドを好まないようです。他のアイデアはありますか？

さて...部分的に解決しました。これを解決済みとしてマークし、新しい問題で新しいスレッドを開始します.....

答えは、CRONがスクリプト（/ home / username / scriptsに保存されている）を実行しようとしたときに、暗号化されたホームディレクトリがマウントされていなかったからだと思います。/ usr / scriptsに移動すると、ジョブは期待どおりに実行されます。

そのため、今ではスパイダーオークの問題のようです。プロセスは開始されますが、ブートプロセスが終了するまでに終了します。何らかの理由でクラッシュするのではないかと思っています。

すべての助けてくれてありがとう！

上記のユーザーが問題を理解する@rebootと、ユーザーのcrontabエントリから解決することができました。

Ubuntuで使用されているcronのバージョンは完全にはわかりませんが、これはユーザーも使用できること@reboot、または後続バージョンのcronのある時点でバグが修正されたことを示しているようです。

データポイント＃4

CentOS 6で次のテストを行ったところ、うまくいきました。

例

$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1

その後、システムを再起動しました。

$ sudo reboot

再起動後。

$ cat reboot.txt 
hi

奪う

1. この機能は、システムとユーザーの両方のcrontabエントリでサポートされているようです。
2. 特定のディストリビューションやcronパッケージのバージョンでサポートされているか、機能していることを確認する必要があります。

実際のメカニズムがどのように機能するかについての詳細@rebootは、内臓について説明しているこのブログ投稿に出会いました。タイトルは@reboot-簡単なcronマジックの説明です。

crondのデバッグ

crondRHEL / CentOS / Fedoraベースのディストリビューションのこの設定ファイルに次を追加することで、詳細度を上げることができます。

$ more crond 
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-L 2"

有効なレベルは0、1、または2です。このファイルをデフォルトのログレベルに戻すに"-L 2"は、状況のデバッグが完了したら、単に削除します。

Ubuntuマシンでは、@ rebootの時点でまだDNSサービスにアクセスできないことがわかりました。これにより、リモートボリュームをマウントできませんでした。この簡潔でありながらシンプルなソリューションが機能しました：

@reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log

（ルートcron;デバッグ用の最後の部分）

Mac OSXもありますが、スクリプトが実行されていないという同じ問題がありました。しかし、私が好きに私のスクリプトを修正したとき

@reboot   cd /home/me/  && sh myscript.sh

私にとってはうまくいきました。次のコマンドを実行して、シェルファイルを実行可能にしてください。

chmod +x myscript.sh

これをすでに解決しているかどうか、または上記のいずれかが必要な解決策であったかどうかはわかりませんが、別の可能性は次のとおりです。

/ homeディレクトリが暗号化されている場合、ログインするまで利用できない可能性があります。つまり、再起動時には利用できません。

このシナリオでは、スクリプトを/ srv、/ opt、/ usr / local / bin /などの別の場所に移動できます。

Ubuntu Gnome 13.10（私の場合はデフォルトのユーザー：avanderneut）を新規インストールします。

avanderneut@uggo:~$ crontab -l
no crontab for avanderneut
avanderneut@uggo:~$ crontab -e
no crontab for avanderneut - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.tiny

Choose 1-3 [2]: 3
crontab: installing new crontab
avanderneut@uggo:~$ crontab -l | tail -2
# m h  dom mon dow   command
@reboot /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ more !$
more /home/avanderneut/bin/on_reboot
#! /bin/bash
echo "Reboot script" > /var/tmp/xxx
avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
xxx
avanderneut@uggo:~$ rm /var/tmp/xxx
avanderneut@uggo:~$ sudo reboot
[sudo] password for avanderneut: 

また、再起動前にファイル/var/tmp/xxxが存在していなかったにもかかわらず、再起動後にファイルが存在することを確認してください。

これは、cronバージョン3.0で行われました。

スクリプトの実行時には利用できないサービスディスクなどが使用されていないことを確認する必要があります。上記のような単純なものから始めて、電子メールがおそらく稼働していないので、端末出力がないことを確認してください。

これがうまくいかず、この機能が必要な場合は、最新のcron（またはoracle-linuxからのアップグレード）が必要になる場合があります。

私は質問に対してイエスと言うでしょう。再起動時にcronを実行するのに問題があり（Debian 3.10.70）、次の方法で解決できました：

@reboot root /usr/bin/python3 /path/to/script

最後に改行文字 「\ n」

これはファイルの内容です：

/etc/cron.d/runOnReboot

最後に、私はそれがからの要約に注目する価値があると思う man 5 crontab

... cronコマンドのフォーマットは、多くの上位互換の拡張機能を備えたV7標準です。各行には5つの時刻と日付のフィールドがあり、コマンド、改行文字（ '\ n'）が続きます。システムのcrontab（/ etc / crontab）は同じ形式を使用しますが、コマンドのユーザー名は時刻フィールドと日付フィールドの後、コマンドの前に指定されます。フィールドはスペースまたはタブで区切られます。コマンドフィールドの最大許容長は998文字です。...

まず、ルートとしてログインする必要があります。

sudo -i

次に、crontabを開きます。

crontab -e

その後、以下のようにスクリプトをrootとしてcrontabに追加します。

@reboot root / home / user1 / Desktop / my_script

その結果、スクリプトが正しく機能することがわかりました。

注：現在のユーザーでcrontabを編集した場合、再起動ではスクリプトを適切に呼び出すことができません。

プルエバ：

usuario @ ubuntu：〜$ touch script.sh usuario @ ubuntu：〜$ chmod + x script.sh

usuario @ ubuntu：〜$ $ crontrab -e

@reboot /home/usuario/script.sh

PCを保存して再起動します