UNIX for Dummies Questions & Answers

Hi guys,

It's me again, I have a scenario and I need your advice...We've install an agent in unix 2.8 and we schedule a job to be run once a week. I've notice that the cron job that we schedule on the console(Other computer, win2k prof.) to be run on the agent is added to the root cron(agent side,unix, loc. /var/spool/cron/crontabs/root). My question is, if the root cron reach its maximum capacity how the unix will handle the incoming cron job from the console. Is the Unix has a mechanism that, if the root cron is loaded already, it will create another root cron file and transfer all the old contents so it will have enough space for incoming cron jobs from the console.

Sorry if I ask too much question, please be bear with me...I'm still a novice...

Kups

I'm not sure of what you are asking but I think you are confusing going from console and changing root's crontab on a system versus going from another server (telnet, ssh....) to a system and changing root's crontab.

The crontab for root is a file (as you specified, /var/spool/cron/crontabs/root). To change the crontab for root, use the crontab -e command (read the man page on crontab first). The system will start some type of editor session - so it's like editing any other file at that point. You make changes, save, and exit the editor.

I have never heard of a maximum capacity for cron - I doubt you could reach it since those of us who have mistakenly created incorrect entries in cron which have created multiple processes in seconds can tell you, it won't be the crontab that gets to a maximum but the server - with runaway processes in endless loops. The most entries I have seen in a crontab to date: 171 (a DBA who has so much running in cron, I don't think he even needs to come to work anymore).

Modern versions of cron do have a limit. At least both HP-UX and Solaris do. And I have bumped into that limit many times. I have never heard on a limit of the number of entries in a crontab or a collection of crontabs. But there is a limit on the max number of sumultaneous cron jobs running. When you exceed this you get a message like this:
! c queue max run limit reached Sat Jul 6 04:00:00 2002
! rescheduling a cron job Sat Jul 6 04:00:00 2002
And yes, I copied that message from the log file on one of our servers.

The message is a little cryptic. If you look at your queuedefs file, you will probably find two lines, one for "at" jobs, and one for "batch" jobs. A third line that starts with a "c" could exist and it would be for cron jobs. In the absence of such a line, the defaults apply. That is 100, so you can have no more than 100 cron jobs running at once. But you can override this by editing your queuedefs file. And this is documented, see "man queuedefs".