The cause of

Crontab is a unix-like task manager based on time, which is widely used in various scenarios. However, the Crontab task sometimes has some strange errors. A node image processing timing script I wrote this week did not execute as expected, but the error content has nothing to do with Cron, and there is no problem with running directly without using cron.

In terms of symptoms, there is a high probability that environmental variables are responsible. Through single step debugging, it was finally located that a third-party library used cross-spwan to execute a command gm, but the third-party library did not process the error case where the gm command was not found. Once the cause is found, use where gm to locate the gm command, declare PATH in the execution script or crontab configuration file header, and cron will run normally.

conclusion

Cron is a very mature tool, generally does not run as expected, you can follow the following ideas to troubleshoot.

The environment variable

The environment variables in CRON may not be the same as those in the system, and we need validation to make sure that they can be used

* * * * * env > /tmp/env.output
Copy the code

Print the environment variables to/TMP /env.output. Compare the contents of env.output with the environment variables obtained by executing env directly on the terminal to see the differences. For example, in this case, the gm does not exist in cron environment variables.

The solution

You can declare the correct PATH variable at the top of the crontab file or shell script file, except that the PATH declared in the crontab file applies to all cron tasks in the file.

Cron daemon

Run the pgrep cron command to check whether the cron daemon process is started. If no number (THE PID of cron) is displayed, the cron daemon process is not started.

The solution

This can be started using sudo systemctl start cron.

Cron newline

Crontab file whether the Crontab file ends with a blank line.

The solution

Check the crontab file and add a newline at the end.

Permission problems

When a non-root user performs cron operations, check whether the cron user has permissions on the file or directory to which the operation is performed. If the permissions are insufficient, cron rejects the operation.

The solution

It is best not to use root for all tasks, which may seem to circumvent the problem and raise more questions about permission management. Cron -cannot access crontab after changing uid -ask Ubuntu

This is a summary of some of the problems we have encountered with CRon, hoping to provide you with some ideas for troubleshooting.

References [askubuntu.com/questions/7 askubuntu.com/questions/7…)