Wo kann ich Umgebungsvariablen setzen, die crontab verwenden soll?

Question

Ich lasse jede Stunde einen Crontab laufen. Der Benutzer, der sie ausführt, hat Umgebungsvariablen in der Datei .bash_profile die funktionieren, wenn der Benutzer den Job vom Terminal aus ausführt, aber offensichtlich werden diese nicht von crontab übernommen, wenn es läuft.

Ich habe versucht, sie in .profile y .bashrc aber sie scheinen immer noch nicht abgeholt zu werden. Weiß jemand, wo ich Umgebungsvariablen einfügen kann, die von crontab übernommen werden können?

Answer 1

Wenn Sie nicht alle Variablen des Profils im Skript einrichten möchten, können Sie die zu exportierenden Variablen oben im Skript auswählen.

In der Datei crontab -e:

SHELL=/bin/bash

*/1 * * * * /Path/to/script/script.sh

In script.sh

#!/bin/bash
export JAVA_HOME=/path/to/jdk

some-other-command

Answer 2

Ich benutze Oh-my-zsh in meinem Macbook, also habe ich viele Dinge ausprobiert, um die crontab-Aufgabe zum Laufen zu bringen, aber schließlich war meine Lösung das Voranstellen der .zshrc vor dem auszuführenden Befehl.

*/30 * * * * . $HOME/.zshrc; node /path/for/my_script.js

Diese Aufgabe wird alle 30 Minuten ausgeführt und verwendet .zshrc Profil, um meinen Knotenbefehl auszuführen.

Vergessen Sie nicht, den Punkt vor dem $HOME var.

Answer 3

Ich habe die meisten der angebotenen Lösungen ausprobiert, aber nichts hat zunächst funktioniert. Es stellte sich jedoch heraus, dass es nicht die Lösungen waren, die nicht funktionierten. Offenbar hat mein ~/.bashrc Datei beginnt mit dem folgenden Codeblock:

case $- in
    *i*) ;;
    *) return;;
esac

Dies ist im Grunde eine case statement die den aktuellen Satz von Optionen in der aktuellen Shell überprüft, um festzustellen, dass die Shell interaktiv läuft. Wenn die Shell tatsächlich interaktiv läuft, wird die Suche nach der ~/.bashrc Datei. In einer Shell, die von cron die $- Variable enthält nicht die i Wert, der die Interaktivität anzeigt. Daher ist der ~/.bashrc Datei wird nie vollständig ausgelagert. Infolgedessen wurden die Umgebungsvariablen nie gesetzt. Wenn dies Ihr Problem ist, können Sie den Codeblock wie folgt auskommentieren und erneut versuchen:

# case $- in
#     *i*) ;;
#     *) return;;
# esac

Ich hoffe, dass sich dies als nützlich erweist

Answer 4

Leider haben Crontabs nur einen sehr begrenzten Umfang an Umgebungsvariablen, so dass Sie diese bei jeder Ausführung des Crontabs exportieren müssen.

Ein einfacher Ansatz wäre das folgende Beispiel: Nehmen wir an, Sie haben Ihre env vars in einer Datei namens env, dann:

* * * * * . ./env && /path/to_your/command

dieser Teil . ./env werden sie exportiert und dann innerhalb des gleichen Bereichs Ihres Befehls verwendet

Answer 5

Ein anderer Weg - inspiriert von diesem diese Antwort - um Variablen zu "injizieren" ist die folgende (fcron Beispiel):

%daily 00 12 \
    set -a; \
    . /path/to/file/containing/vars; \
    set +a; \
    /path/to/script/using/vars

から help set :

-a Markieren Sie Variablen, die für den Export geändert oder erstellt werden.

Die Verwendung von + anstelle von - bewirkt, dass diese Flaggen deaktiviert werden.

Also alles, was dazwischen liegt set - y set + wird exportiert nach env und ist dann für andere Skripte usw. verfügbar. Ohne die Verwendung von set die Variablen werden ausgelagert, leben aber in set nur.

Abgesehen davon ist es auch nützlich, Variablen zu übergeben, wenn ein Programm von einem Nicht-Root-Konto ausgeführt werden muss, Sie aber einige Variablen in der Umgebung dieses anderen Benutzers benötigen. Unten sehen Sie ein Beispiel für die Übergabe von nullmailer-Variablen zur Formatierung der E-Mail-Kopfzeile:

su -s /bin/bash -c "set -a; \
                    . /path/to/nullmailer-vars; \
                    set +a; \
                    /usr/sbin/logcheck" logcheck