I'd like to write an app that heavily use cron. It'll execute python programs that run in less than a second every minute.

How mane of this lines:

*/1 * * * * python crtip.py parameters

my crontab -l can have? How does it works? Does it fork for each scheduled job?


  • 2
    Not sure. It's about cron's internal code and how to use in while coding. – Juanjo Conti Feb 15 '10 at 14:30
  • */1 is the same as *. As for limits, I suspect if you're bumping up against any OS-level limits you're using it wrong. Have you considered making a daemon to run these tasks? – ceejayoz Feb 15 '10 at 14:58
  • 2
    What cron daemon are you talking about? I'm the current developer of Dillon's cron, and I could give you an answer for that. But there's also Vixie cron, fcron, bcron, ... Vixie cron is the most widely deployed cron daemon on *nix, so if I have to guess, I guess you're talking about that. – dubiousjim Feb 16 '10 at 16:41

To address your questions:

  • How many lines may crontab have?

I'm not aware of any maximum number of lines in crontab. However, more than a few hundred lines is probably fairly uncommon (hence not well-tested), and also hard to maintain. So I'd probably avoid exceeding that.

  • Does it fork for each scheduled job?


That said, cron is not really commonly used for the kind of thing you describe. If you need to invoke a program so frequently and with so many different parameters, writing some kind of daemon / server process is probably more appropriate. Advantages would be:

  • nice, unified logging (instead of messages being dumped into cron's log or mailed)
  • more control about when programs run (and precision of more than one minute)
  • more performance, as you don't need to always fork internally
  • easier to maintain/install than a gigantic crontab

Maybe you could describe in more detail how many invocations you need, with which parameters, and for what purpose. Then we can help better.


Here are answers for one cron daemon, dillon's cron (dcron) which I'm the current developer of. There are a variety of cron daemons in distribution, and the answers are going to be different. Vixie cron is probably the most widespread; I don't know the answers for that.

Anyway, for dillon's cron, a user can have 256 significant lines in their crontab (this is configurable at compile time). Root can have many more than that (I think 65535). Plus root can have multiple crontabs (the one at /var/spool/cron/crontabs/root, plus as many additional ones as you want in /etc/cron.d/).

Cron commands are only run one once a minute, at the top of the minute. You could have 60 different commands run every minute, and just prefix them with sleep 1, sleep 2, and so on. But I doubt this is the best solution for what you have in mind.

Yes, in our implementation each cronjob forks into a separate process. If there's any output to stdout or stderr, yet another process is forked to mail it.


Yes, it will fork for every cronjob. But if your server is even moderately powerful, I think you will not encounter any problems very soon. My personal home pages are running on a very old Pentium III 1.1 GHz / 512 MB RAM / slow IDE HD, and it does not suffer from running around 15 different cronjobs every hour.

If your cronjobs are extremely cpu or I/O hungry, then your mileage may vary, but the "they run in less than a second" part makes me think you will not see any problems whatsoever. Go ahead, think something more complex if time tells you to do so.


I had a simular problem, having to manage a lot of processes in my crontab. What I did was write one main script, which listed all executable files and links in a certain folder (provided on the commandline) and executed them consecutively. This script I put in crontab with for example the "monitor" parameter, which would run every minute and execute all scripts in "$BASEFOLDER/monitor". This way, you can also have entries that launch every hour, on certain days, once in the morning, once in the evening, ...

My main script does a lot more than that, like provide a certain guaranteed set of environment variables, unified logging and some application-specific things, but I hope you get the idea. This is somewhat simular to the cron.daily/cron.hourly system some distributions use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.