45

I have defined "SHELL" variable in /etc/crontab file:

[martin@martin ~]$ grep SHELL /etc/crontab 
SHELL=/usr/local/bin/bash
[martin@martin ~]$ file /usr/local/bin/bash
/usr/local/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.0 (800107), stripped
[martin@martin ~]$ 

In addition, all my scripts in /etc/crontab file are started under user "martin". However /home/martin/.bash_profile(for login shell) and /home/martin/.bashrc(for non-logging shell) contain some variables which are ignored in case of cron job, but are used in case I log into machine over SSH or open new bash session. Why cron ignores those variables? Isn't cron simply executing "/usr/local/bin/bash my-script.sh" with permissions for user "martin"?

67
+100

You can source the file you want at the top of the script or beginning of the job for the user that is executing the job. The "source" command is a built-in. You'd do the same thing if you made edits to those files to load the changes.

* * * * * source /home/user/.bash_profile; <command>

or

#!/bin/bash
source /home/user/.bash_profile

<commands>
  • 2
    Note that "source" might not work if cron is not using the bash shell. I've added an answer that can handle the case when the shell is sh. – Jonathan May 3 '17 at 7:40
  • ^ source not found error fix – Danny Bullis Feb 1 '18 at 1:33
21

Because it's not an interactive shell. The same happens when you open some terminals.

Have a look at this question: What is the .bashrc file? | Super User

And also at this one:

What's the difference between .bashrc, .bash_profile, and .environment? | Stack Overflow

Different scripts fire depending on if the connection is a login shell (or not), an interactive shell (or not), or both.

If you want to make bashrc you'll need to make this change:

When Bash is started non-interactively, to run a shell script, for example, it looks for the variable BASH_ENV in the environment, expands its value if it appears there, and uses the expanded value as the name of a file to read and execute. Bash behaves as if the following command were executed:

if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi 

but the value of the PATH variable is not used to search for the file name.

As noted above, if a non-interactive shell is invoked with the --login option, Bash attempts to read and execute commands from the login shell startup files.

Source: Bash Startup Files | Bash Reference Manual | gnu.org

  • So if we set BASH_ENV inside Cron, cron bash scripts will source that because cron is non-interactive and non-login. – CMCDragonkai Dec 11 '15 at 7:19
11

You may not be able to run source if the sh shell is being used. This can be changed by adding the following line in your crontab:

SHELL=/bin/bash
* * * * * source "/root/.bashrc"; <command>

You can also specify the environment:

BASH_ENV="/root/.bashrc"
* * * * * <command>

or you can use your local /home/user/.bashrc if it is a user cron job (e.g. crontab -e).

Note that .bash_profile can replace .bashrc, if it exists.

Credit: How to change cron shell (sh to bash)?

  • this works well also for Acquia Cloud Scheduled jobs, which are basically cron jobs. You can do the same, like: SHELL=/bin/bash && source /home/YOUR_USER_NAME/.bash_profile && sh .... – Alejandro Moreno Jan 22 at 17:58
0

bash acts differently whether it is a shell or a normal progamming language (like perl or python).

By designed, those settings in ~/.bash_profile, ~/.bashrc, etc. are for users to set things when bash plays the roll of a shell (login shell, interractive shell). Think about environment you have in a xterm (interractive shell) or in ssh sessions (login shell) or in consoles (login shell).

In other hand, bash is also a powerfull progamming language --think about many scripts for managing services in systemd-- which requires a different style of working. Example, when a developer write a system script or a bash program, he/she will not likely to source user defined ~/.bash_profile automatically. It is a normal program, not a shell. A normal program (including bash programs) would naturally inherrit setting in a current working evironement (shell), but not set them.

If we write a program for cron in bash --it is just happenly it is written in bash; in fact, we can write it in python or perl or any other progamming language-- then, we can have an option to sources bash's ~/.bash_profile (read: setting of user's shell, which happenly to be the same language of your programming language):

[ -f /home/user/.bash_profile ] && . /home/user/.bash_profile

However, what if that particular user do not use bash as his/her shell? He/she may use zsh, 'ksh,fish`, etc. So, that's practice does not really work when writing program for public use.

So, you can source ~/.bash_profile if you think it work. But, here, it is not about whether we are able to source a file, it is about how things should works in the system: the design concept. In short: we should view bash as something having 2 rolls: shell and progamming language. Then everything will be clear, easier to understand.

0

Something else that might interfere with the sourcing of your .bashrc from a cronjob is any checks that this file does in order to detect interactive shells.

For example, on Ubuntu 18.04, the default .bashrc for a user starts with this:

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

and so sourcing it won't do anything useful since it will exit immediately.

-1

My way to deal with it was this:

1) Putting my variables in (the end of) ~/.profile:

myVarInDotProfile="someValue"

2) Creating a Bash script for my (daily) cron tasks (~/cronDaily.sh) containing my commands plus repetitive sourcing of ~/.profle:

source ~/.profile
command ${myVarInDotProfile}/

3) scheduling my script's execution from crontab, to run daily:

0 0 * * * bash ~/cronDaily.sh

My variable wasn't ignored and the commands ran successfully.


Some may say such intense sourcing of ~/.profile is problematic. In my particular case I don't see why it is a problem but I would advice to consider creating a dedicated file for that.

In general, there might be a better way to this but that's what worked for me after a lot of pain and it explains the principle that as of Bash 4.3.46, you cannot source a file from crontab.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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