Here is MySQL on CentOS.

I would like to execute Update SQL at 24:05 every day.

Therefore, I created a sh file.
The inside is written like this.

mysql -h localhost -u user -ppassword lang -e "SET SQL_SAFE_UPDATES = 0;UPDATE table SET member_type = 1 WHERE id = 20;"

If i enter the following on the terminal, it will be updated properly.
Command line #'/home/user/document/mysql_everyday.sh'

But when I run it as cron, Update doesn't work well.
Contents of cron.conf file
5 0 * * *'/home/user/document/mysql_everyday.sh'
(Other sh files that are run regularly are also listed here, and they work normally.)

If i enter a shell file name in the terminal and press Enter, it works.
Is not all sh files work with cron?

One thing I'm worried about is when I enter the shell file name in the terminal, the following warning appears.

mysql: [Warning] Using a password on the command line interface can be insecure.
/home/user/document/mysql_everyday.sh: line 4:/root: directory

If anyone is familiar, please give me an answer.

  • Answer # 1


    Is not all sh files work with cron?

    Any command that doesn't need to interact with humans can be run with cron.

    If you have configured to send mail from that OS, cron errors will be notified by email from root to the running user.
    If you find it difficult to set up email,
    5 0 * * * /home/user/document/mysql_everyday.sh 2>/tmp/errormsg
    Confirm the error message with.

    The difference between running from the command line and running from cron is
    ・ Current directory
    ・ Environment variables
    Standard input/output, error output
    is. In many cases, environment variables, especiallyPATH, affect execution differences.

  • Answer # 2

    When running as cron,environment variablessuch as$PATHare different from the login shell.

    First of all, let's verify that what is the problem by running it with cron so that the log is properly output.

  • Answer # 3

    I'm sorry.

    I was misunderstood.
    Thank you for telling me how to output and analyze logs.

    Forgetting to use the Crontab command led to the solution of this issue.

    I'm sorry for all the noise.