Comment puis-je exécuter une commande cron avec des variables d'environnement existantes?

Comment puis-je exécuter une commande cron avec des variables d'environnement existantes?

Si je suis à l'invite du shell, je peux taper echo $ORACLE_HOMEet obtenir un chemin. C’est l’une de mes variables environnementales qui est définie dans mes ~/.profile. Cependant, il semble que les ~/.profilescripts ne soient pas chargés et, par conséquent, mes scripts échouent car la $ORACLE_HOMEvariable n'est pas définie.

Dans cette question, l'auteur mentionne la création d'un ~/.cronfileprofil définissant des variables pour cron, puis il effectue une solution de contournement pour charger toutes ses commandes cron dans des scripts qu'il conserve dans son ~/Cronrépertoire. Un fichier ~/.cronfileressemble à une bonne idée, mais le reste de la réponse semble un peu lourd et j'espérais que quelqu'un pourrait me dire un moyen plus facile d'obtenir le même résultat.

Je suppose qu'au début de mes scripts, je pourrais ajouter quelque chose du genre source ~/.profilemais cela semble être redondant.

Alors, comment puis-je faire en sorte que mes scripts cron chargent les variables à partir de mon profil de shell interactif?

Dans la crontab, avant de commander, ajoutez . $HOME/.profile. Par exemple:

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

Cronne sait rien de votre coquille; il est démarré par le système, il a donc un environnement minimal. Si vous voulez quelque chose, vous devez l'avoir vous-même.

Une autre option, que je trouve plus facile, consiste à exécuter le script avec cron et à inclure l’environnement dans le script.

Dans le fichier crontab -e:

SHELL=/bin/bash

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

Dans le fichier cron_job.sh:

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

Toute commande après la source de .bash_profile aura votre environnement comme si vous vous étiez connecté.

Une autre option, que je trouve plus facile, est d’exécuter le script avec cron et d'indiquer à bash de se connecter (d'où l'utilisation de /etc/profile.d/...définitions d'environnement).

En crontab -efichier:

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

Toute commande après la source de .bash_profileaura votre environnement comme si vous vous êtes connecté.

Mauvaise idée. La pratique générale consiste à définir spécifiquement toutes les variables d'environnement requises dans un script à exécuter à partir d'un travail cron.

Cette syntaxe vous aide vraiment. Je ne comprends pas la syntaxe, mais ça marche. Oracle utilise cette syntaxe lors du déploiement d'Oracle Configuration Manager sur crontab. Par conséquent, j'estime qu'il s'agit d'une bonne solution.

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

Je suis récemment tombé sur un cas dans lequel je devais exécuter le travail global de cron en tant que root tout en exécutant une sous-commande en tant qu'utilisateur différent (ce qui nécessitait de rechercher l'environnement de cet utilisateur). Je suis allé avec l'approche suivante:

# 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

La partie cruciale est l'argument -iqui est passé et sudoqui exécutera la commande donnée dans un shell de connexion séparé (ce qui signifie que les fichiers de points de l'utilisateur seront générés).

PS: Notez que la usercolonne est uniquement disponible dans /etc/crontabet les /etc/cron.d/*fichiers.

La solution qui a fonctionné pour moi est décrite ici .

Vous créez un script wrapper qui appelle . ~/.cronfilepuis fait les choses que vous voulez. Ce script est lancé par cron.

Dans ~/.cronfilevous spécifiez l'environnement pour vos tâches cron.

Oui, vous pouvez utiliser des "solutions de contournement bien connues" (dont certaines ont été répertoriées). C’est une autre façon de dire que tout le monde sait que c’est de la merde, bien que certaines personnes qualifient cela de "dispositif de sécurité" le temps perdu n'était pas pour rien. C'est l'équivalent cron du clavier QWERTY.

Je soupçonne que la raison initiale était peut-être liée aux performances, de telle sorte que les scripts exécutés une fois par minute ne prennent pas le temps de lire des scripts rc. De plus, à l'origine, cron n'était pas vraiment configurable, donc un paramètre par défaut était vraiment la seule option.

Il n’ya pas de sécurité supplémentaire en n’ayant pas une configuration ou une méthode simple permettant à cron de s’occuper uniquement de l’environnement de votre shell interactif au lieu d’obliger les utilisateurs à effectuer une gymnastique de shell stupide. Sur une machine moderne, les gains de performance ne sont généralement pas perceptibles, sauf si vous avez une grande quantité de travaux en cours d'exécution à la minute.

La culture Unix échoue. À mon humble avis. :-)

Ajouter

BASH_ENV=/home/user/.profile

à la crontab. Voir Comment garantir la disponibilité de $ BASH_ENV

Au lieu de définir le profil, ce qui m’a aidé a été de définir le PATH. Certaines des commandes n'étaient pas disponibles dans mes scripts cron, car elles PATHsont différentes.

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

Définir PATHavec le chemin des commandes m'a aidé. Encore mieux si vous pouvez utiliser un modèle et désemployer plus tard,

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

Passer des variables à chaque élément semble compliqué.

Je mets . ~/.dbus/session-bus/*au sommet de mon script désiré :)