Environment Variable Used in Shell Script Appear Blank in Log File When Run by Cron

Environment variable used in shell script appear blank in log file when run by cron

There's your problem: cron doesn't run /etc/profile.

cron is started with only a tiny number of environment settings; anything else you need, you have to set up yourself, so it's customary to have cron call a script to handle the setup and then the main action.

I have a crontab entry that calls a bash script. Why does $USER return blank?

As suggested in the comments, cron uses a rather minimal environment, with most of the environment variables undefined, and a very short $PATH. In many versions of crontab, you can define the variables you need at the top of the crontab file, like so:

USER=foo
BAR=baz
PATH=/bletch:/bazoo:"$PATH"

Shell script isn't working correctly on crontab, works when manually called

Things you should check out:

1. Is /path/to/script/script.sh 1&2 > /tmp/output valid in your cron? On my machine, it would run the script with argument "1" and try to find a program called "2" to run it. Failing to find it, it creates an empty output file. I think you're looking for something like /path/to/script/script.sh >> /tmp/output 2>&1
2. Do you set CURL to the full path of curl? Cron normally doesn't have the same path information that you have.
3. Which user do you use for running cron? Could there be access restrictions to curl or the network?
4. % is indeed handled differently by cron, if it's written in the crontab. It means newline, and should otherwise be escaped. Have you been running tests with curl directly in cron? As long as you keep this in your script you should be fine.

crontab run shell script that write user history into a log file

Comment from fedorqui is correct.
Also, you shoud add a username in crontab file (if you use "/etc/crontab").

For example:

*/2 * * * *  USERNAME  /bin/bash /home/user/history.sh

Bash empty variable after running cron, but runs manually

Qualifying /usr/bin/nmcli isn't enough -- you're calling a bunch of other tools that need to be found from the PATH also.

Also, in general -- when debugging a cron job, arrange for its stderr to go to a file, like so:

#!/bin/bash

# log stdout and stderr to two different files
exec >>/var/log/looog.log 2>>/var/log/looog.err.log

# ...and log every command we try to execute to stderr (aka looog.err.log)
set -x

# set a PATH variable
export PATH=/bin:/usr/bin

# original code here, using modern POSIX $() syntax, vs old hard-to-nest ``
gwip=$(nmcli dev list iface eth0 | awk '/IP4-SETTINGS[.]GATEWAY:/ { print $2}')
printf '%s\n' "$(date) =- $gwip -= "

---

The key things here are the explicitly-set PATH (not having the value you expect set in PATH is a common issue in cron jobs), and the stderr log (which ensures that any other issues can be identified by reading its contents).

Note the use of a single redirection to looog.log up-front. This doesn't make a significant difference when you're literally only running one print statement, but if you would have extended this script to have more than one, it's more efficient to open your output file only one than to re-open it every time you have something to write.

---

Related Topics