Crontab non-effective solution of ENV environment variable caused by Linux

Crontab is a scheduled task in Linux, but the task plan before the persecution using the ENV environment variable is not working, let's look at how to solve the crontab problem caused by the ENV environment variable.

   

A friend said that he wrote a script to do the scheduled task to back up the database, but the backup is not successful, manual execution of the script is not a problem, and in the/var/log/cron log to see the successful execution, but is not see the backup database files.

With SSH permissions, after the login, after reading, and what he said, the script executes successfully, but no backup is generated.

However, check the email sent to root and see the problem:
Return-path: <root@test.com>
X-original-to:root
Delivered-to:root@test.com
From:root@test.com (Cron Daemon)
To:root@test.com
Subject:cron <root@test> sh/data/cron/backup.sh
Content-type:text/plain; Charset=utf-8
auto-submitted:auto-generated
X-cron-env: <lang=en_us. Utf-8>
X-cron-env: <SHELL=/bin/sh>
X-cron-env: <HOME=/root>
X-cron-env: <PATH=/usr/bin:/bin>
X-cron-env: <LOGNAME=root>
X-cron-env: <USER=root>
Date:tue, 1 APR 2014 10:58:01-0400 (EDT)
Status:r

/data/cron/backup.sh:line 27:mysql:command not found

From the above can be seen, said the MySQL command did not find, and then executed a command:

[Root@test data]# Echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/nginx/sbin:/usr/local/mysql/ Bin

This is where the problem is, the execution environment variables in crontab are inconsistent with the environment variables set by the root user, and the difference can be seen from the above two:
Environment variables in crontab: x-cron-env: <PATH=/usr/bin:/bin>

environment variable for root user:
path=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/nginx/sbin:/usr/local/ Mysql/bin

Now that we know that the MySQL command is placed under/usr/local/mysql/bin, and Crontab's path variable does not, there is a problem mysql:command not found.

At the same time, we can create a new script that validates the path variable in crontab:
[Root@test data]# VI path.sh
#!/bin/bash

Echo $PATH

# after saving, add to Crontab

[Root@test data]# Crontab-e
*/1 * * * */data/path.sh

After 1 minutes, you can see:

/usr/bin:/bin

Know the problem, that is good to solve, there are two kinds:

1. In the backup script, set it manually, for example:

#!/bin/bash

. /etc/profile

.... The rest ...
Here needs ". /etc/profile ", is because the friend MySQL compiles itself, adds the MySQL path all to here:
Path= $PATH: $HOME/bin:/usr/local/nginx/sbin:/usr/local/mysql/bin
Export PATH

2. Directly set the user's crontab, add path/usr/local/mysql/bin, for example:
[Root@test data]# Crontab-e
Shell=/bin/bash
path=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/nginx/sbin:/usr/local/ Mysql/bin:/root/bin
Mailto=root
home=/

0 */12 * * * sh/data/cron/backup.sh

After you save it, you can back it up normally.

You can also learn about a file/etc/crontab:
[root@test data]# cat/etc/crontab
Shell=/bin/bash
Path=/sbin:/bin:/usr/sbin :/usr/bin
Mailto=root
home=/
 
# for details, man 4 crontabs
 
# Example of Job Defin Ition:
#.----------------minute (0-59)
# | .-------------Hour (0-23)
# |  | .--------- -Day of Month (1-31)
# |  |  | .-------month (1-12) OR jan,feb,mar,apr ...
# |  |  |  | .----Day of Week (0-6) (sunday=0 or 7) or Sun,mon,tue,wed,thu,fri,sat
# |&NB Sp. |  |  |  |
# *  *  *  *  * user-name command to be executed