web-dev-qa-db-ja.com

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

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

シェルプロンプトにいる場合は、echo $Oracle_HOMEと入力してパスを取得できます。これは、~/.profileで設定される環境変数の1つです。ただし、~/.profileがcronスクリプトから読み込まれないため、$Oracle_HOME変数が設定されていないため、スクリプトが失敗します。

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

スクリプトの最初にsource ~/.profileのようなものを追加できると思いますが、それは冗長であるように思えます。

では、cronスクリプトでインタラクティブシェルプロファイルから変数をロードするにはどうすればよいですか？

shellenvironment-variablescron
126
cwd

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

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

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

154
Arcege

私がより簡単だと思う別のオプションは、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のソースの後のコマンドは、ログインした場合と同じように環境を設定します。

45
Robert Brisita

私がより簡単だと思う別のオプションは、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のソースの後のコマンドは、ログインした場合と同じように環境を設定します。

24
Artistan

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

10
fpmurphy

この構文は間違いなく役立ちます。構文はわかりませんが、動作します。 Oracleは、Oracle Configuration Managerをcrontabにデプロイするときにこの構文を使用するため、これが正しいソリューションであると私は信じています。

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters
6
meir

グローバル環境変数を/etc/environment。これらは、プログラムがcrontabによって実行されるときにロードされます。例：

env | grep Oracle_HOME >> /etc/environment
service crontab restart

欠点は、それが単一のユーザーに制限されないことです。 CentOS7でテスト済み

3
Kiruahxh

最近、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

重要な部分は引数-iSudoに渡されます。これにより、別のログインシェルで指定されたコマンドが実行されます（つまり、ユーザーのドットファイルが読み込まれます）。

PS：user列は/etc/crontab そしてその /etc/cron.d/*ファイル。

2
balu

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

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

ユーザーが愚かなシェル体操を行わなくても、cronがインタラクティブシェルの環境を引き継ぐだけの簡単な構成や方法がないことによるセキュリティの追加はありません。最近のマシンでは、毎分大量のジョブを実行しない限り、一般に知覚できるパフォーマンスの向上はありません。

Unix文化は失敗します。私の愚見で。 :-)

1
Austin S.

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

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

各項目に変数を渡すのは面倒に見えます。

1
Optimus Prime

私にとってうまくいった解決策は here で説明されています。

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

~/.cronfileでは、cronジョブの環境を指定します。

1
weekens

追加

BASH_ENV=/home/user/.profile

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

1
Enno