既存の環境変数を使用してcronコマンドを実行するにはどうすればよいですか？

既存の環境変数を使用してcronコマンドを実行するにはどうすればよいですか？

シェルプロンプトが表示されている場合はecho $ORACLE_HOME、パスを入力して取得できます。これは、環境変数の1つです~/.profile。ただし、~/.profilecronスクリプトがロードされないため、$ORACLE_HOME変数が設定されていないためスクリプトが失敗します。

で、この質問の著者は、作成言及~/.cronfilecronのための変数を設定したプロファイルを、その後、彼は彼が彼に続けてスクリプトにすべての彼のcronコマンドをロードするための回避策ありません~/Cronディレクトリを。ファイルのよう~/.cronfileなものは良いアイデアのように聞こえますが、答えの残りの部分は少し扱いに​​くいようで、誰かが同じ結果を得る簡単な方法を教えてくれることを望んでいました。

スクリプトの開始時に次のようなものを追加できると思いますが、source ~/.profileそれは冗長になる可能性があるようです。

では、どのようにしてcronスクリプトに対話型シェルプロファイルから変数を読み込ませることができますか？

コマンドを実行する前に、crontabでを追加し. $HOME/.profileます。例えば：

0 5 * * * . $HOME/.profile; /path/to/command/to/run

Cronシェルについて何も知りません。システムによって開始されるため、最小限の環境です。何かが必要な場合は、それを自分自身に持ち込む必要があります。

私が簡単だと思うもう1つのオプションは、cronでスクリプトを実行し、スクリプトに環境を設定することです。

crontab -eファイルで：

SHELL=/bin/bash

*/1 * * * * $HOME/cron_job.sh

cron_job.shファイル内：

#!/bin/bash
source $HOME/.bash_profile
some_other_cmd

.bash_profileのソースの後のコマンドには、ログインしたかのように環境があります。

私が見つけやすい別のオプションは、cronでスクリプトを実行し、bashにログインするよう指示することです（したがって、/etc/profile.d/...環境定義を使用します）

でcrontab -eファイル：

*/1 * * * * bash -l -c './cron_job.sh'
*/1 * * * * bash -l -c 'php -f ./cron_job.php'

のソースの後のコマンドには、.bash_profileログインしたかのように環境があります。

悪いアイデア。一般的な方法は、cronジョブから実行されるスクリプトに必要なすべての環境変数を具体的に設定することです。

この構文は間違いなくあなたを助けます。構文はわかりませんが、機能します。Oracleは、Oracle Configuration Managerをcrontabにデプロイするときにこの構文を使用するため、これが正しいソリューションであると考えています。

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

最近、cronジョブ全体をrootとして実行する必要があるが、同時に別のユーザーとしてサブコマンドを実行しなければならないケースに遭遇しました（そのユーザーの環境を調達する必要がありました）。私は次のアプローチで行った：

# m  h  dom  mon  dow  user  command
*/5  *   *    *    *   root  (sudo -i -u <the user> command-to-be-run-as-user) && command-to-be-run-as-root

重要な部分は、別のログインシェルで指定されたコマンドを実行するため-iに渡される引数ですsudo（これは、ユーザーのドットファイルが取得されることを意味します）。

PS：user列は/etc/crontabと/etc/cron.d/*ファイルでのみ利用可能であることに注意してください。

私のために働いた解決策は、ここで説明されています。

ラッパースクリプトを作成し、これを呼び出して. ~/.cronfile、必要な処理を行います。このスクリプトは、cronによって起動されます。

では~/.cronfileもしあなたのcronジョブのための環境を指定します。

はい、「よく知られている回避策」を使用できます（そのうちのいくつかがリストされています）。これは誰もがそれが安っぽいことを知っているという別の言い方ですが、一部の人々はこれを「セキュリティ機能」と呼んでいます。無駄な時間は無駄ではありませんでした。これはQWERTYキーボードに相当するcronです。

元々の理由はパフォーマンスのためだったのではないかと思われます。1分に1回実行されるスクリプトはrcスクリプトを読むのに時間を費やさないでしょう。また、もともとcronは実際にはまったく設定可能ではなかったため、デフォルトが実際に唯一のオプションでした。

ユーザーが愚かなシェルの体操を行う代わりに、cronがインタラクティブシェルの環境を引き継ぐための簡単な構成や方法がないため、セキュリティが追加されません。最新のマシンでは、毎分実行される膨大な量のジョブがない限り、一般に目に見えるほどのパフォーマンスの向上はありません。

Unixカルチャーは失敗します。私の愚見で。:-)

追加

BASH_ENV=/home/user/.profile

crontabへ。$ BASH_ENVの可用性を保証する方法を参照してください

プロファイルを設定する代わりに、私が助けたのはを設定することPATHでした。一部のコマンドは、cronスクリプトでは使用できないため、使用できませんでしたPATH。

ENVIRONMENT=prod
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

PATHコマンドのパスを設定することは私を助けました。テンプレートを使用して、後でテンプレート化を解除できる場合は、

ENVIRONMENT={{ENVIRONMENT}}
PATH={{PATH}}
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

各アイテムに変数を渡すのは面倒です。

置いた 。~/.dbus/session-bus/*目的のスクリプトの上部にある:)