Linux Cron Running principle

1. Preface

This article describes a cron run on SuSE Linux that was developed by Paul Vixie. Can be confirmed by "man Cron".

2. Example

# examples are used to match the instructions in this article

*/1 * * * * echo Hello >>/tmp/hello.txt

3. Working Process

Cron does a check every minute to see which command is executable.

As you can see, there are 4 fork, these 4 fork are:

1) The first fork, let Cron itself become daemon process, that is to become the Guardian process;

2) The second fork, when Cron checks to have a command to execute when it is created, but note that it does not execute the command, execute the command by its child process to do;

3) The third fork, some versions call vfork, but some version is fork, it is responsible for executing the cron command process, that will call Execle () process;

4) The fourth fork is not required, only standard input is configured for CRON commands to be used:

*/1 * * * */tmp/x/x%1234567890

Like a percentile "%" above, followed by a string, there will be a fourth fork, its role is to "%" after the content as standard input to the third fork out of the process.

Note that the fork-out process does not ignore (ignore) the pipe signal (sigpipe), so if you encounter sigpipe, it will cause the process to silently exit, such as the standard input Output redirect pipeline read end is closed, write will trigger sigpipe.

In practice, you may encounter child_process () in doing the above mentioned third fork before the sigpipe signal exits, leading to incomprehensible problems. One of the phenomena is that the cron command was executed several times, but it was never executed again, because the second fork came out of the process because Sigpipe exited, resulting in no third fork, so the cron command was not called (always called by Execle ()).

4. An odd question

You may encounter this situation, assuming that there is one of the following configurations in Cron:

*/1 * * * * echo Hello >>/tmp/hello.txt

After observing how many times it normally runs, it is no longer running, or once, but there is no other problem to confirm, so it is very strange.

The cause of this problem, it is possible because there is a shared library hook cron, shared library code triggered the sigpipe, resulting in the second fork out of the process to exit, did not have time to execute vfork.

Fork out of the sub-process, no processing of sigpipe, the default behavior is to silently quit the process. By modifying/etc/ld.so.preload, you can inject a shared library into a non-associative process, which can be observed through LDD, and the same effect can be achieved with ld_preload.

5. Cron&crontab

Cron is a daemon that runs in the background, and crontab is a tool for setting up cron. Cron dispatches the/etc/crontab file.

6. Cron.allow&cron.deny

Crontab uses two files, and Cron doesn't use them.

7. Cron.daily&cron.hourly&cron.weekly&cron.monthly

The four directories of cron.daily, Cron.hourly, cron.weekly and cron.monthly are located in/etc, but Cron and crontab two are not processed. They are handled by run-crons configured in/etc/crontab, Run-crons is a shell script file located under directory/usr/lib/cron:

# Cat/etc/crontab

Shell=/bin/sh

Path=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin

Mailto=root

#

# Check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly

#

-*/15 * * * * root test-x/usr/lib/cron/run-crons &&/usr/lib/cron/run-crons >/dev/null 2>&1

8. Crontab Post-edit cron exception

With crontab editing, Cron stuck (not the process stuck, but the command was not called), probably because "TCB table full", the simplest way is to restart Cron.

It is recommended that you avoid writing the following nested command statements, which may cause cron to not work correctly:

*/1 * * * * echo "' Date +%h:%m:%s ' Hello ' >>/tmp/hello.txt

"Date" is nested in "echo" and can be changed to a script call or without nesting commands, such as:

*/1 * * * * echo "Hello" >>/tmp/hello.txt

One phenomenon is that there is a cron subprocess (as described in 14786 below) that does not exit:

# Ps-ef|grep Cron

Root 10325 1 0 15:08? 00:00:00/usr/sbin/cron

Root 14786 10325 0 15:13? 00:00:00/usr/sbin/cron

GDB sees the call stack as:

#0 0xffffe410 in __kernel_vsyscall ()

#1 0xb7e88a63 in __read_nocancel () from/lib/libc.so.6

#2 0xb7e38e38 in _io_file_read_internal () from/lib/libc.so.6

#3 0XB7E3A0BB in _io_new_file_underflow () from/lib/libc.so.6

#4 0XB7E3A7FB in _io_default_uflow_internal () from/lib/libc.so.6

#5 0xb7e3bb2d in __uflow () from/lib/libc.so.6

#6 0xb7e35b7b in getc () from/lib/libc.so.6

#7 0x80005d73 in?? () From/usr/sbin/cron

Strace See the following:

# strace-f-P 14786

Process 14786 attached

Read (7,

With lsof you can see:

Cron 14786 root 7r FIFO 0,6 117960708 Pipe

For a pipeline, read () hangs because the process at the other end of the pipeline calls _exit () exits instead of calling exit ().

This time only manually kill this pending cron child process.

Linux Cron Running principle