cron process - info

hi all,

Using: SUN Box

say,
there are n-crontab files from n-users ( excluding the user entries those who are restricted from making use of the cron )

the cron daemon parses the files every one minute ( with a minimum granularity of one minute - hope so !!! )

here falls my question,

How is the cron able to parse n-files simultaneously ?
Do cron spawn n-instances to parse the files( i dont think so)?
Does it follow any order in parsing the n-files if not concurrently?
Or
All the cron entries from all the n-users maintained as single entry differentiated by userid?

Hope I am clear with the question.

the cron daemon parses the files every one minute

It is not accurate. There is no such polling at one minute interval.

In fact, cron sets a timer at the time of the next event and then it goes to sleep, waiting the timer to wakeup it again. When this happens it executes the related job.

Every time you edit the cron jobs (by crontab -e) the timer is re-scheduled to reflect any changes in the files.

that is really cool,

thanks for the reply,

Every time you edit the cron jobs (by crontab -e) the timer is re-scheduled to reflect any changes in the files.

i cannot understand rather accept it !!!

Let me put your statement this way,

a cronjob x, under the id 'y' to be scheduled at 11:02
and the cron is right now put to sleep and waiting for the timer to wake it up again.

when doing a crontab -e for some other id 'z' spawning over the time frame of 11:02 will that not rescheudle the cron timer.

If that is so how is the job x under the id 'y' is guaranteed to run at 11:02?

Hope I am clear with the doubt!!!

The user id does not matter in this discussion. Only the cron job time matter.
When the cron process is started at boot time, it will scan all cron jobs, building a chronological list of jobs. The timer is set to the first one in the list.
When this time arrive, the cron job is started (or cron jobs, if there is more than one), the first entry in the list is removed and the timer is set again for the first in the list. This continues forever.

When a new job is created/changed by crontab -e, the chronological list of jobs is rebuild.

I hope this can explain better the process. If not, please, ask again and I will make my best.

RTFM
man cron

Good point !
I did read the cron code in C, several years ago, as part of a College project and we wrote a report about our findings and this was discussed with the rest of class.

I think either the man page does not reflect the current implementation, or the current implementation was changed over the years.

For anyone interested in this subject, reading the code is the only way to be sure how cron works. I already did.

regards,

the first entry in the list is removed and the timer is set again for the first in the list. This continues forever.

thanks a lot marozsas,
that was a very good reply,

regarding removing from the list i believe you are trying to mention the logical representations.

First I will look in to the code.

Thanks once again.

Since bigearsbilly post, I was curious about what is the current
implementation of cron. The things I learned at school are still valid or that one minute polling the cron man pages talk about has something to do with the real implementation ?

Well, looks like the current GNU implementation of cron is a work from Paul Vixie (http://en.wikipedia.org/wiki/Paul_Vixie) and it uses a one minute polling approach. From the cron-4.1-20.src.rpm:

/* ... wait for the time (in minutes) to change ... */
                do {
                        cron_sleep(timeRunning + 1);
                        set_time(FALSE);
                } while (clockTime == timeRunning);
                timeRunning = clockTime;

The "cron_sleep(timeRunning + 1)" is the key here. No doubt about. Vixie's implementation use a one minute polling.

But, if you search the Google for cron code that not belongs to Paul Vixie ("cron.c -vixie") you will find several listings that uses that "time event based queue" I described in my first reply.
None is recent. The most recent is from 2003.

So, I was wondering if there is a good technical reason to this shift or just is an author's preference.

Talking with a few friends about it, someone pointed the Paul Vixie's approach can detects changes in crontab files just by checking its modified time.

The former approach depends on "crontab -e" to signaling the cron process that something has changed. Of course, restarting cron will do the job too. This is the way several modern daemons work today (squid, samba, named etc).

Answering your question, looks like cron builds its internal database AFTER it runs the pending jobs. There is a lot of time to do that before the next minute arrives.

I hope this post makes the things more clear. Sorry all of you, for any mistake and for my poor English.

best regards,