mjhjmtu

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.

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.

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. :-)

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