Where can I set environment variables that crontab will use?

You can define environment variables in the crontab itself when running crontab -e from the command line.

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

This feature is only available to certain implementations of cron. Ubuntu and Debian currently use vixie-cron which allows these to be declared in the crontab file (also GNU mcron).

Archlinux and RedHat use cronie which does not allow environment variables to be declared and will throw syntax errors in the cron.log. Workaround can be done per-entry:

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

I got one more solution for this problem:

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

In this case it will pick all the environment variable defined in your $HOME/.profile file.

Of course $HOME is also not set, you have to replace it with the full path of your $HOME.

Setting vars in /etc/environment also worked for me in Ubuntu. As of 12.04, variables in /etc/environment are loaded for cron.

If you start the scripts you are executing through cron with:

#!/bin/bash -l 

They should pick up your ~/.bash_profile environment variables

Expanding on @carestad example, which I find easier, is to run the script with cron and have the environment in the script.

In crontab -e file:

SHELL=/bin/bash */1 * * * * $HOME/cron_job.sh 

In cron_job.sh file:

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

Any command after the source of .bash_profile will have your environment as if you logged in.

Whatever you set in crontab will be available in the cronjobs, both directly and using the variables in the scripts.

Use them in the definition of the cronjob

You can configure crontab so that it sets variables that then the can cronjob use:

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

Now the file /tmp/hello shows things like:

$ 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 

Use them in the script run by cronjob

You can configure crontab so that it sets variables that then the scripts can use:

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

And say script /tmp/myscript.sh is like this:

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

It generates a file /tmp/myoutput.res showing:

$ 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 ... 

For me I had to set the environment variable for a php application. I resolved it by adding the following code to my crontab.

$ sudo crontab -e 

crontab:

ENVIRONMENT_VAR=production * * * * * /home/deploy/my_app/cron/cron.doSomethingWonderful.php 

and inside doSomethingWonderful.php I could get the environment value with:

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

I hope this helps!

Instead of

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

Use bash -l -c

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

You can also prepend your command with env to inject Environment variables like so:

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

Expanding on @Robert Brisita has just expand , also if you don't want to set up all the variables of the profile in the script, you can select the variables to export on the top of the script

In crontab -e file:

SHELL=/bin/bash */1 * * * * /Path/to/script/script.sh 

In script.sh

#!/bin/bash export JAVA_HOME=/path/to/jdk some-other-command 

I'm using Oh-my-zsh in my macbook so I've tried many things to get the crontab task runs but finally, my solution was prepending the .zshrc before the command to run.

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

This task runs every 30 minutes and uses .zshrc profile to execute my node command.

Don't forget to use the dot before the $HOME var.

I tried most of the provided solutions, but nothing worked at first. It turns out, though, that it wasn't the solutions that failed to work. Apparently, my ~/.bashrc file starts with the following block of code:

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

This basically is a case statement that checks the current set of options in the current shell to determine that the shell is running interactively. If the shell happens to be running interactively, then it moves on to sourcing the ~/.bashrc file. However, in a shell invoked by cron, the $- variable doesn't contain the i value which indicates interactivity. Therefore, the ~/.bashrc file never gets sourced fully. As a result, the environment variables never got set. If this happens to be your issue, feel free to comment out the block of code as follows and try again:

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

I hope this turns out useful

Unfortunately, crontabs have a very limited environment variables scope, thus you need to export them every time the corntab runs.

An easy approach would be the following example, suppose you've your env vars in a file called env, then:

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

this part . ./env will export them and then they're used within the same scope of your command

Another way - inspired by this this answer - to "inject" variables is the following (fcron example):

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

From help set:

-a Mark variables which are modified or created for export.

Using + rather than - causes these flags to be turned off.

So everything in between set - and set + gets exported to env and is then available for other scripts, etc. Without using set the variables get sourced but live in set only.

Aside from that it's also useful to pass variables when a program requires a non-root account to run but you'd need some variables inside that other user's environment. Below is an example passing in nullmailer vars to format the e-mail header:

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

All the above solutions work fine.

It will create issues when there are any special characters in your environment variable.

I have found the solution:

eval $(printenv | awk -F= '{print "export " "\""$1"\"""=""\""$2"\"" }' >> /etc/profile)

None of the above worked for me. What did work was:

* * * * * /usr/bin/bash -ic "your_command" 

or wherever your bash is located. Double quotes are important. -i causes bash to be interactive and .bashrc will be processed.

For me I had to specify path in my NodeJS file.

// did not work!!!!! require('dotenv').config() 

instead

// DID WORK!! require('dotenv').config({ path: '/full/custom/path/to/your/.env' }) 

I found this issue while looking at a similar problem that matched the title, but I am stuck with the environment file syntax that systemd or docker use:

FOO=bar BAZ=qux 

This won't work for Vishal's excellent answer because they aren't bash scripts (note the lack of export).
The solution I've used is to read each line into xargs and export them before running the command:

0 5 * * * export $(xargs < $HOME/.env); /path/to/command/to/run 

• Set Globally env

sudo sh -c "echo MY_GLOBAL_ENV_TO_MY_CURRENT_DIR=$(pwd)" >> /etc/environment" 

• Add scheduled job to start a script

crontab -e */5 * * * * sh -c "$MY_GLOBAL_ENV_TO_MY_CURRENT_DIR/start.sh" 

=)

I ran into this problem today where I had to get following scenario working:

1. debian-slim image with required tools
2. Expose set of ENV variables as part of k8s deployment (deplopyments.yaml)
3. Make the variables available to my cron job.

How did I do it?

Container Spec (k8s pod):

 spec: containers: - name: my-container image: my-registry-host/my-image:1.1.0_DV9qfuY37AWw imagePullPolicy: IfNotPresent command: ["/bin/bash", "-c", "/apps/my-awesome-app/scripts/startup.sh"] ... env: - name: ENV_VAR1 value: "env-var1-value" - name: ENV_VAR2 value: "env-var2-value" - name: ENV_VAR3 value: "env-var3-value" 

Dockerfile

... RUN crontab -l | { cat; echo "*/15 14-19 23 * * /apps/my-awesome-app/scripts/cronsjob.sh >> cronjob-journal.log"; } | crontab - ... 

/apps/my-awesome-app/scripts/startup.sh listing ENV_VAR1, ENV_VAR2, ENV_VAR3 are exposed to the pod (as shown above):

... #Make all the environment variables available to crontab shell(s) crontab -l | { echo "ENV_VAR1=${ENV_VAR1}";cat; } | crontab - crontab -l | { echo "ENV_VAR2=${ENV_VAR2}";cat; } | crontab - crontab -l | { echo "ENV_VAR3=${ENV_VAR3}";cat; } | crontab - ... # Other startup commands/scripts ... 

Validation/Verification

1) kubectl exec -i -t <podname> -n <namespace> -- bash 2) execute `crontab -l` 3) Verify the following listing ENV_VAR1=env-var1-value ENV_VAR2=env-var2-value ENV_VAR3=env-var3-value */15 14-19 23 * * /apps/my-awesome-app/scripts/cronsjob.sh >> cronjob-journal.log 

Now all 3 of your environment variables are available to /apps/my-awesome-app/scripts/cronsjob.sh when cron scheduler invokes it.

what worked for me (debian based):

1. create a file with all the needed env var :

   #!/bin/bash
   env | grep VAR1= > /etc/environment
   env | grep VAR2= >> /etc/environment
   env | grep VAR3= >> /etc/environment
   

2. then build the crontab content, by calling the env file before calling the script that needs it, therefore start the cron service

   (crontab -l ; echo '* * * * * . /etc/environment; /usr/local/bin/python /mycode.py >> /var/log/cron-1.log 2>&1') | crontab
   service cron start

nb : for python use case, be sure to call the whole python path, else wrong python could be invocated, generating non-sense syntax error