Look at this crontab down here.
* * * * * * */usr/bin/python/home/zhangdapeng/del.py >/dev/null 2>&1
Generally safer, without disturbing the case is like this
But debugging is inconvenient, the error, do not know why the error, can't find the reason, change
* * * * * * */usr/bin/python/home/zhangdapeng/del.py >/path/result.log 2>&1
That way, you can know the reason in Result.log.
Actually, I think one of the most common problems with Crontab is that the environment variables are wrong. You will often see someone in the forum asking, "Why did my Crontab create a no execution?" When you're ready to create a Cron JOB, a lot of people like to run it at the command line, because the environment variable is automatically brought in with the Shell, and in Crontab, the job cannot be executed because the correct environment variable is not found. This little problem is like smallpox, after a lesson is remembered.
A skill that must be used
After each JOB completes, the system automatically sends the output to the current system user. Over and over, very much, even the whole system will explode. So it is necessary to redirect each JOB command back: >/dev/null 2>&1. The premise is that the normal output of the commands in the JOB needs to be processed, such as appending to a particular log file.