Wie kann ich einen Cron-Befehl mit vorhandenen Umgebungsvariablen ausführen?

Wie kann ich einen Cron-Befehl mit vorhandenen Umgebungsvariablen ausführen?

Wenn ich an einer Shell-Eingabeaufforderung bin, kann echo $ORACLE_HOMEich einen Pfad eingeben und abrufen. Dies ist eine meiner Umgebungsvariablen, die in my gesetzt wird ~/.profile. Es scheint jedoch, dass von ~/.profileCron-Skripten keine geladen werden und meine Skripten fehlschlagen, weil die $ORACLE_HOMEVariable nicht gesetzt ist.

In dieser Frage erwähnt der Autor das Erstellen eines ~/.cronfileProfils, das Variablen für cron einrichtet, und führt dann eine Problemumgehung durch, um alle seine cron-Befehle in Skripten zu laden, die er in seinem ~/CronVerzeichnis aufbewahrt. Eine Datei ~/.cronfileklingt nach einer guten Idee, aber der Rest der Antwort scheint etwas umständlich zu sein, und ich hatte gehofft, jemand könnte mir einen einfacheren Weg nennen, um das gleiche Ergebnis zu erzielen.

Ich nehme an, zu Beginn meiner Skripte könnte ich so etwas hinzufügen, source ~/.profileaber das scheint so, als könnte es überflüssig sein.

Wie kann ich meine Cron-Skripte dazu bringen, die Variablen aus meinem Interactive-Shell-Profil zu laden?

Fügen Sie in der Crontab, bevor Sie befehlen, hinzu . $HOME/.profile. Zum Beispiel:

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

Cronweiß nichts über deine Muschel; Es wird vom System gestartet, daher ist die Umgebung minimal. Wenn Sie etwas wollen, müssen Sie das selbst mitbringen.

Eine andere Möglichkeit, die ich einfacher finde, besteht darin, das Skript mit cron auszuführen und die Umgebung im Skript zu haben.

In der crontab -e Datei:

SHELL=/bin/bash

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

In der cron_job.sh Datei:

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

Bei jedem Befehl nach der Quelle von .bash_profile ist Ihre Umgebung so, als ob Sie angemeldet wären.

Eine andere Möglichkeit, die ich einfacher finde, ist, das Skript mit cron auszuführen und bash anzuweisen, sich anzumelden (daher /etc/profile.d/...Umgebungsdefinitionen zu verwenden).

In der crontab -eDatei:

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

Jeder Befehl nach der Quelle von .bash_profilehat Ihre Umgebung so, als ob Sie angemeldet wären.

Schlechte Idee. In der Regel werden alle erforderlichen Umgebungsvariablen in einem Skript festgelegt, das von einem Cron-Job ausgeführt werden soll.

Diese Syntax hilft Ihnen auf jeden Fall. Ich verstehe die Syntax nicht, aber es funktioniert. Oracle verwendet diese Syntax, wenn Oracle Configuration Manager für Crontab bereitgestellt wird. Daher halte ich dies für eine richtige Lösung.

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

Ich bin kürzlich auf einen Fall gestoßen, in dem ich den gesamten Cronjob als root ausführen musste, gleichzeitig aber einen Unterbefehl als anderer Benutzer ausführen musste (was die Beschaffung der Umgebung dieses Benutzers erforderte). Ich bin mit folgendem Ansatz vorgegangen:

# 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

Der entscheidende Teil ist das Argument -i, an sudodas übergeben wird, um den angegebenen Befehl in einer separaten Anmeldeshell auszuführen (was wiederum bedeutet, dass die Punktedateien des Benutzers bezogen werden).

PS: Beachten Sie, dass die userSpalte nur in /etc/crontabund den /etc/cron.d/*Dateien verfügbar ist .

Die Lösung, die bei mir funktioniert hat, ist hier beschrieben .

Sie erstellen ein Wrapper-Skript, das aufruft . ~/.cronfileund dann die gewünschten Aktionen ausführt. Dieses Skript wird von cron gestartet.

In ~/.cronfilelegen Sie die Umgebung für Ihre Cronjobs fest.

Ja, Sie können "bekannte Problemumgehungen" verwenden (von denen einige aufgelistet wurden). Dies ist eine andere Art zu sagen, dass jeder weiß, dass es beschissen ist, obwohl einige Leute dies als "Sicherheitsmerkmal" bezeichnen werden, weil sie mindestens so viel über dieses Versagen (ure) gestolpert haben, wie Sie es getan haben, und gerne an ihr denken würden Zeitverschwendung war nicht umsonst. Es ist das Cron-Äquivalent der QWERTZ-Tastatur.

Ich vermute, dass der ursprüngliche Grund für die Leistung war, so dass Skripte, die einmal pro Minute ausgeführt werden, nicht die Zeit zum Lesen von RC-Skripten verschwenden würden. Auch ursprünglich war cron überhaupt nicht konfigurierbar, so dass ein Standard die einzige Option war.

Es gibt keine zusätzliche Sicherheit, da cron keine einfache Konfiguration oder Methode hat, um nur die Umgebung Ihrer interaktiven Shell zu übernehmen, anstatt dass Benutzer dumme Shell-Gymnastik machen müssen. Auf einer modernen Maschine ist in der Regel kein Leistungszuwachs erkennbar, es sei denn, Sie haben jede Minute eine große Menge von Aufträgen ausgeführt.

Unix-Kultur scheitert. Meiner bescheidenen Meinung nach. :-)

Hinzufügen

BASH_ENV=/home/user/.profile

zur Crontab. Siehe So stellen Sie die Verfügbarkeit von $ BASH_ENV sicher

Anstatt ein Profil festzulegen, half mir das Festlegen des PATH. Einige der Befehle waren in meinen Cron-Skripten nicht verfügbar, da dies PATHanders ist.

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

Das Setzen PATHmit dem Befehlspfad hat mir geholfen. Noch besser, wenn Sie eine Vorlage verwenden und später wieder nachdenken können,

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

Das Übergeben von Variablen an jedes Element sieht unordentlich aus.

Ich legte . ~/.dbus/session-bus/*ganz oben auf meinem Wunschskript :)