Où puis-je définir les variables d'environnement que crontab utilisera?

J'ai un crontab qui fonctionne toutes les heures. L'utilisateur qui l'exécute a un environnement variable dans ce .bash_profilequi fonctionne lorsque l'utilisateur exécute le travail à partir du terminal, cependant, évidemment, ceux-ci ne sont pas récupérés par crontab lors de son exécution.

J'ai essayé de les installer .profileet .bashrcmais ils ne semblent toujours pas être récupérés. Est-ce que quelqu'un sait où je peux placer des variables d'environnement que crontab peut récupérer?

Demandez à «cron» d'exécuter un script shell qui définit l'environnement avant d'exécuter la commande.

Toujours.

#   @(#)$Id: crontab,v 4.2 2007/09/17 02:41:00 jleffler Exp $
#   Crontab file for Home Directory for Jonathan Leffler (JL)
#-----------------------------------------------------------------------------
#Min     Hour    Day     Month   Weekday Command
#-----------------------------------------------------------------------------
0        *       *       *       *       /usr/bin/ksh /work1/jleffler/bin/Cron/hourly
1        1       *       *       *       /usr/bin/ksh /work1/jleffler/bin/Cron/daily
23       1       *       *       1-5     /usr/bin/ksh /work1/jleffler/bin/Cron/weekday
2        3       *       *       0       /usr/bin/ksh /work1/jleffler/bin/Cron/weekly
21       3       1       *       *       /usr/bin/ksh /work1/jleffler/bin/Cron/monthly

Les scripts dans ~ / bin / Cron sont tous des liens vers un seul script, 'runcron', qui ressemble à:

:       "$Id: runcron.sh,v 2.1 2001/02/27 00:53:22 jleffler Exp $"
#
#       Commands to be performed by Cron (no debugging options)

#       Set environment -- not done by cron (usually switches HOME)
. $HOME/.cronfile

base=`basename $0`
cmd=${REAL_HOME:-/real/home}/bin/$base

if [ ! -x $cmd ]
then cmd=${HOME}/bin/$base
fi

exec $cmd ${@:+"$@"}

(Écrit en utilisant une ancienne norme de codage - de nos jours, j'utiliserais un shebang '#!' Au début.)

Le '~ / .cronfile' est une variation de mon profil pour une utilisation par cron - rigoureusement non interactif et sans écho pour être bruyant. Vous pouvez organiser l'exécution du fichier .profile, etc. à la place. (La substance REAL_HOME est un artefact de mon environnement - vous pouvez prétendre que c'est la même chose que $ HOME.)

Ainsi, ce code lit l'environnement approprié, puis exécute la version non Cron de la commande à partir de mon répertoire personnel. Ainsi, par exemple, ma commande «en semaine» ressemble à:

:       "@(#)$Id: weekday.sh,v 1.10 2007/09/17 02:42:03 jleffler Exp $"
#
#       Commands to be done each weekday

# Update ICSCOPE
n.updics

La commande «quotidienne» est plus simple:

:       "@(#)$Id: daily.sh,v 1.5 1997/06/02 22:04:21 johnl Exp $"
#
#       Commands to be done daily

# Nothing -- most things are done on weekdays only

exit 0

Vous pouvez définir des variables d'environnement dans la crontab elle-même lors de l'exécution à crontab -epartir de la ligne de commande.

LANG=nb_NO.UTF-8
LC_ALL=nb_NO.UTF-8
# m h  dom mon dow   command

* * * * * sleep 5s && echo "yo"

Cette fonctionnalité n'est disponible que pour certaines implémentations de cron. Ubuntu et Debian utilisent actuellement vixie-cron qui permet de les déclarer dans le fichier crontab (également GNU mcron ).

Archlinux et RedHat utilisent cronie qui ne permet pas de déclarer les variables d'environnement et générera des erreurs de syntaxe dans cron.log. Une solution de contournement peut être effectuée par entrée:

# m h  dom mon dow   command
* * * * * export LC_ALL=nb_NO.UTF-8; sleep 5s && echo "yo"

J'ai une solution de plus pour ce problème:

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

Dans ce cas, il sélectionnera toutes les variables d'environnement définies dans votre $HOME/.profilefichier.

Bien sûr, $HOMEn'est pas non plus défini, vous devez le remplacer par le chemin complet de votre $HOME.

La configuration de vars a /etc/environmentégalement fonctionné pour moi dans Ubuntu. Depuis le 12.04, les variables dans /etc/environmentsont chargées pour cron.

Si vous démarrez les scripts que vous exécutez via cron avec:

#!/bin/bash -l

Ils devraient récupérer vos ~/.bash_profilevariables d'environnement

Développer l'exemple de @carestad, que je trouve plus facile, est d'exécuter le script avec cron et d'avoir 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é.

Pour moi, j'ai dû définir la variable d'environnement pour une application php. Je l'ai récupéré en ajoutant le code suivant à ma crontab.

$ sudo  crontab -e

crontab:

ENVIRONMENT_VAR=production

* * * * * /home/deploy/my_app/cron/cron.doSomethingWonderful.php

et à l'intérieur de doSomethingWonderful.php j'ai pu obtenir la valeur de l'environnement avec:

<?php     
echo $_SERVER['ENVIRONMENT_VAR']; # => "production"

J'espère que ça aide!

Tout ce que vous définissez crontabsera disponible dans les cronjobs, directement et en utilisant les variables dans les scripts.

Utilisez-les dans la définition du cronjob

Vous pouvez configurer de crontabmanière à définir des variables que le cronjob peut utiliser:

$ crontab -l
myvar="hi man"
* * * * * echo "$myvar. date is $(date)" >> /tmp/hello

Maintenant, le fichier /tmp/hellomontre des choses comme:

$ cat /tmp/hello 
hi man. date is Thu May 12 12:10:01 CEST 2016
hi man. date is Thu May 12 12:11:01 CEST 2016

Utilisez-les dans le script exécuté par cronjob

Vous pouvez configurer de crontabsorte qu'il définit des variables que les scripts peuvent ensuite utiliser:

$ crontab -l
myvar="hi man"
* * * * * /bin/bash /tmp/myscript.sh

Et disons que le script /tmp/myscript.shest comme ceci:

echo "Now is $(date). myvar=$myvar" >> /tmp/myoutput.res

Il génère un fichier /tmp/myoutput.resmontrant:

$ cat /tmp/myoutput.res
Now is Thu May 12 12:07:01 CEST 2016. myvar=hi man
Now is Thu May 12 12:08:01 CEST 2016. myvar=hi man
...

Développer sur @Robert Brisita vient de se développer, également si vous ne voulez pas configurer toutes les variables du profil dans le script, vous pouvez sélectionner les variables à exporter en haut du script

Dans le fichier crontab -e:

SHELL=/bin/bash

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

Dans script.sh

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

some-other-command

Au lieu de

0  *  *  *  *  sh /my/script.sh

Utilisez bash -l -c

0  *  *  *  *  bash -l -c 'sh /my/script.sh'

J'utilise Oh-my-zshdans mon macbook, j'ai donc essayé beaucoup de choses pour que la tâche crontab s'exécute, mais finalement, ma solution ajoutait .zshrcavant l'exécution de la commande.

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

Cette tâche s'exécute toutes les 30 minutes et utilise le .zshrcprofil pour exécuter ma commande de nœud.

N'oubliez pas d'utiliser le point avant le $HOMEvar.

Une autre façon - inspirée de cette réponse - d'injecter des variables est la suivante (exemple fcron):

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

De help set:

-a Marquer les variables modifiées ou créées pour l'exportation.

L'utilisation de + plutôt que - provoque la désactivation de ces indicateurs.

Donc , tout le reste set -et set +obtient exporté vers envet est alors disponible pour d' autres scripts, etc. Sans utiliser setles variables sont remplacées mais provenant en direct setseulement.

En plus de cela, il est également utile de transmettre des variables lorsqu'un programme nécessite un compte non root pour s'exécuter, mais vous aurez besoin de certaines variables dans l'environnement de cet autre utilisateur. Vous trouverez ci-dessous un exemple de transmission de vars nullmailer pour formater l'en-tête de l'e-mail:

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

J'ai essayé la plupart des solutions fournies, mais rien n'a fonctionné au début. Il s'avère cependant que ce ne sont pas les solutions qui n'ont pas fonctionné. Apparemment, mon ~/.bashrcfichier commence par le bloc de code suivant:

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

Il s'agit essentiellement d'un case statementqui vérifie l'ensemble d'options actuel dans le shell actuel pour déterminer que le shell fonctionne de manière interactive. Si le shell s'exécute de manière interactive, il passe ensuite au sourcing du ~/.bashrcfichier. Cependant, dans un shell appelé par cron, la $-variable ne contient pas la ivaleur qui indique l'interactivité. Par conséquent, le ~/.bashrcfichier n'est jamais entièrement approvisionné. Par conséquent, les variables d'environnement n'ont jamais été définies. Si cela vous arrive, n'hésitez pas à commenter le bloc de code comme suit et réessayez:

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

J'espère que cela s'avère utile

Vous pouvez également ajouter votre commande avec envpour injecter des variables d'environnement comme ceci:

0 * * * *   env VARIABLE=VALUE /usr/bin/mycommand