How can I run a cron command with existing environmental variables?

If I am at a shell prompt I can type echo $ORACLE_HOME and get a path. This is one of my environmental variables that gets set in my ~/.profile. However, it seems that ~/.profile does not get loaded fron cron scripts and so my scripts fail because the $ORACLE_HOME variable is not set.

In this question the author mentions creating a ~/.cronfile profile which sets up variables for cron, and then he does a workaround to load all his cron commands into scripts he keeps in his ~/Cron directory. A file like ~/.cronfile sounds like a good idea, but the rest of the answer seems a little cumbersome and I was hoping someone could tell me an easier way to get the same result.

I suppose at the start of my scripts I could add something like source ~/.profile but that seems like it could be redundant.

So how can I get make my cron scripts load the variables from my interactive-shell profile?

  • How is adding source ~/.profile to a program redundant? Programs inherit their environment from the calling program. If that calling program is not your shell, then how will the decendant program get the environment that you want? – Arcege Dec 21 '11 at 5:08
  • I already wrote my answer to a similar question here. It simply uses su -l to setup a normal login environment including the $PATH for either root or other specific user. – tasket Sep 14 at 18:52

11 Answers 11

up vote 122 down vote accepted

In the crontab, before you command, add . $HOME/.profile. For example:

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

Cron knows nothing about your shell; it is started by the system, so it has a minimal environment. If you want anything, you need to have that brought in yourself.

  • 11
    What does the . before the script do? (not sure how I would man that). Why is this different from source? – cwd Dec 21 '11 at 19:26
  • 15
    The . command is the original command for source. They are equivalent within the shell and a bit easier to type, especially within a crontab. To get more info, type help . or search for ^SHELL BUILTIN COMMANDS in the man page for bash or at the top of man zshbuiltins. Running type .` will tell you that the command is a builtin. – Arcege Dec 21 '11 at 19:38
  • 9
    Depending on Linux distributions, you may need to change .profile by .bash_profile. Check which .profile file exists in the user's home directory. – Frosty Z May 17 '13 at 12:37
  • @Arcege This doesn't work for me (Fedora Core 21), and I presume that's because the shell level drops back down. Instead, what DOES work is if you source it. – Richard T Apr 14 '15 at 20:56
  • 3
    It's likely that if it isn't working, it's because the SHELL for the cron script isn't set to bash, so it's not executing the same way you might expect. – Dan Farrell Jul 10 '15 at 18:32

Another option, 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.

  • 4
    When running on an AWS Linux AMI, it didn't even occur to me that cron wouldn't be using /bin/bash as the shell. I kept wondering why things like cd /path/to/project; source .vars would work when I typed them manually but would fail (File not found) when included in a cronjob. The key line for me was setting SHELL=/bin/bash so that I could actually use familiar bash commands in each cronjob. /bin/sh/ (the default cron shell, apparently) is very limiting. – Hartley Brody Sep 9 '16 at 14:05
  • It's too bad you can't specify Environment Files at the top of the cron like you can specify individual environment variables. Systemd has a EnvironmentFile service unit. Too bad cron doesn't have something similar. – radtek Jan 30 at 20:19
  • you FORCE all scripts to use /bin/bash in all crontab, which is not a good idea, also what is about your cron line: */1 * * * * $HOME/cron_job.sh … */1 is good for WHAT ?!? one star means it will be executed every minute /1 means will be executed every minute, as an answer in a smart community this is a nasty sin, now I believe you are very confused to say the best … sorry – THESorcerer Aug 24 at 10:48
  • 1
    This is what is called an example. Feel free to adjust to your needs or don't use it at all. Different strokes for different folks. – Robert Brisita Aug 24 at 11:00

Another option, which I find easier, is to run the script with cron and tell bash to login (hence using /etc/profile.d/... environment definitions)

In crontab -e file:

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

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

Bad idea. The general practice is to specifically set all required environmental variables in a script that is to be run from a cron job.

  • I agree with @fpmurphy, that ways it also ensure the secured process environment. If you want to set only few variables from cron you can use /usr/bin/env command to set the variables and then can act as the environment process for the cronjob. – Nikhil Mulley Dec 21 '11 at 6:24
  • daemontools' envdir comes to mind, too. – sr_ Dec 21 '11 at 9:42
  • 5
    I am all for security, but perhaps I can create a file ~/.cronvars and include that in the profile and also in my cron scripts. I don't want to hard code environmental variables in each of the scripts I run because when paths change hard coded paths in each file are not easy to maintain. Seems like that would allow a centralized place for the needed variables and still keep other variables from being loaded. – cwd Dec 21 '11 at 23:21

This syntax definitely helps you. I do not understand the syntax, but it works. Oracle uses this syntax, when deploys Oracle Configuration Manager to crontab, hence, I believe that this is a right solution.

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

The solution, which worked for me, is described here.

You create a wrapper script, which calls . ~/.cronfile, and then does the things you want. This script is launched by cron.

In ~/.cronfile you specify the environment for your cron jobs.

Add

BASH_ENV=/home/user/.profile

to the crontab. See How to guarantee availability of $BASH_ENV

Instead of setting profile, what helped me was setting the PATH. Some of the commands were not available in my cron scripts as the PATH is different.

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

Setting PATH with the path of commands helped me. Even better if you can use a template and detemplatize later,

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

Passing variables to each item looks messy.

I recently came across a case where I had to execute the overall cronjob as root but, at the same time, had to execute a subcommand as a different user (which required sourcing that user's environment). I went with the following approach:

# 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

The crucial part is the argument -i that's being passed to sudo which will execute the given command in a separate login shell (which in turn means that the user's dotfiles will be sourced).

PS: Note that the user column is only available in /etc/crontab and the /etc/cron.d/* files.

Yes, you can using "well known workarounds" (a couple of which have been listed). This is another way of saying that everyone knows it's crappy, though some people will refer to this as a "security feature" because they have spent at least as much tripping over this fail(ure) as you have, and would like to think their wasted time wasn't for naught. It's the cron equivalent of the QWERTY keyboard.

I suspect the original reason may have been for performance, such that scripts run once a minute wouldn't spend the time to read rc scripts. Also originally cron wasn't really configurable at all, so a default was really the only option.

There is no added security by not having some simple configuration or method to have cron just take on the environment of your interactive shell instead of users having to perform stupid shell gymnastics. On a modern machine there is generally no perceptible performance gain unless you have a vast quantity of jobs running every minute.

Unix culture fail. In my "humble" opinion. :-)

  • 1
    "There is no added security." That is not true. Take a look at CVE-2011-1095, CVE-2008-4304, and CVE-2010-3847. – user26112 Jul 26 '13 at 2:20
  • I downvoted your answer, by the way. I usually try to avoid downvoting newcomers' answers but security is important to me. Please don't take the downvote the wrong way. Besides the part about security, your answer is excellent and would deserve an upvote. You can edit your answer here if you would like. – user26112 Jul 26 '13 at 2:33
  • None of those have the slightest thing to do with having cron use a shell with the interactive flag set. This is pure FUD. Unfortunately I can't downvote your downvote. This may seem like a flame, but it's very frustrating when people think a vehicle with three wheels is better because there's a security issue to put a fourth wheel on. It isn't. People have just ridden a tricycle so long they've forgotten it's possible to add a fourth wheel. – Austin S. Jul 26 '13 at 16:43
  • Put another way: if any of the intended extra hoops the other answerers suggested are used, how do they not also gain access to any of the holes you mention? "* * * * * exec bash -i -c LOCALE=......." – Austin S. Jul 26 '13 at 16:56
  • This reads like a rant. I don't even see where it answers the question at all. Even if the security part were removed, @EvanTeitelman, I don't see why it would deserve an upvote as it doesn't answer the question. – Wildcard Jul 21 '17 at 1:15

I put . ~/.dbus/session-bus/* at the top of my desired script :)

  • 1
    Welcome to U & L SE. Please expand your answer more so that it will benefit the readers. – Ramesh Sep 20 '14 at 15:25

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.