How does Linux determine whether Crontab is running normally?

Preface

In the process of our development, we often encounter situations where scheduled tasks are not executed as expected. In the Linux system, timing tasks are generally implemented by the system Crontab. This article discusses how to judge whether the Crontab is running normally.

text

We all know that to check which Crontabs are configured by the user, the following commands are generally used:

crontab -l

In fact, the above command checks the Crontab configured by the currently logged in user. What if you need to check the Crontab of a specified user? At this time, we need to specify user parameters through -u on the crontab command, as follows:

crontab -u username -l

The premise of executing this command is that the current user has the permission to view the specified user Crontab. Normally, only root can view the Crontab of all users.

In some cases, we may just take over the project, and it is not clear which user Crontab is configured under. What should we do in this case?

If the user you are currently logged in is not the root user or does not have the sudo permission, you need to grant the account sudo permission first, because viewing the Crontab of all users requires root special permission.

With root authority, we can see the Crontab set by all current users in the /var/spool/cron/ directory:

ll /var/spool/cron/
-rw------- 1 root root 1405 May 29 11:40 root
-rw------- 1 root root 420 May 29 11:40 www

Here we can see the Crontab file named after the user name. Open the file to view the details of Crontab set by all users.

In this way, what we see is the current configuration content of Crontab. If we want to view the execution of Crontab history, we can track it by viewing Crontab's execution log:

ll -h /var/log/cron*
-rw------- 1 root root 806K May 29 20:12 /var/log/cron
-rw------- 1 root root 3.3M May 7 03:17 /var/log/cron-20230507
-rw------- 1 root root 3.3M May 14 03:25 /var/log/cron-20230514
-rw------- 1 root root 3.3M May 21 03:08 /var/log/cron-20230521
-rw------- 1 root root 3.3M May 28 03:20 /var/log/cron-20230528

By default, Crontab's logs are recorded in the /var/log/cron file, and will be divided by the week as the dividing point.

Here we find the corresponding log file according to the time range we need to locate, and then perform a matching search based on the keyword:

cat /var/log/cron | grep 'keywords'

From the log, we can see whether the task is invoked, the user who invoked it, the time it was invoked, and the details of the command invoked. With this information, we can know whether the scheduled task has been executed in the past time.

The above is how to locate whether the Crontab is executed correctly. So now the question is, what operations may cause Crontab to fail to execute normally?

When encountering this kind of problem, we generally investigate from the following aspects:

• Whether the time scheduling configuration is correct (can be self-checked through https://crontab.guru/ URL)
• Whether the command can be called normally (generally we choose to use the absolute path of the command, also to avoid the problem that the command cannot be parsed in the environment variable)
• The problem of file permissions (whether the file operated by the command or the file redirected output has permission)
• Insufficient disk space

We can take the command out of Crontab and execute it in the corresponding user environment to see if it can be executed normally. Similarly, when Crontab fails to execute, you can also see the corresponding error information in the log, through which we can also locate the problem.