Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

It feels like there are use cases for things you'd want to run once every 5 seconds, twice a minute, etc, but these are impossible with cron. Why hasn't second-level cron granularity been built into modern operating systems? (Or has it and I don't know..?)

share|improve this question

migrated from programmers.stackexchange.com Jul 17 '13 at 9:55

This question came from our site for professional programmers interested in conceptual questions about software development.

    
cron is just a program... there's nothing preventing you from writing something similar that will run every second. But, as MichaelT brings up... the need for such may be an indication that whatever it is you are doing perhaps may instead call for a different approach, such as a dedicated daemon. –  GrandmasterB Jul 17 '13 at 5:33

1 Answer 1

In short, compatibility.

The format that crontab uses is described in minute detail as part of the POSIX Specification. Linux distros are generally not 100% fully compliant with the POSIX specs, but they are generally very close, as most of the things in the POSIX spec are the parts of a Unix-like machine that developers take for granted as existing. As far as Cron goes, the Linux Standard Base specifies rather directly that it should behave as per POSIX.

Certainly, individual distros might choose to modify the Cron they use, but Adding second-level granularity would require another field, making the new crontab effectively completely incompatible with virtually everything that uses Cron.

But, pointing out that it's for compatibility doesn't really give us any insight as to why it's granular only at the minute level. So, why has Cron always used minute-level granularity?

Well, I wasn't exactly there (nor even born at the time), but I suspect it's due to the way Cron was first implemented.

The cron in Version 7 Unix, written by Brian Kernighan, was a system service (later called daemons) invoked from /etc/inittab when the operating system entered multi-user mode. Its algorithm was straightforward:

1.Read /usr/etc/crontab

2.Determine if any commands must run at the current date and time, and if so, run them as the superuser, root.

3.Sleep for one minute

4.Repeat from step 1.

A Cron implementation based on a sleep loop would almost certainly break down miserably with finer granularity than one minute; as it is, Cron had to be rewritten to use more efficient methods in order to be able to handle loads on the order of 100 users. One-second granularity would be even worse than that at just two users.

So, because the program initially couldn't handle it, and because the format has continued on, and because changing it would be a rather large compatibility break, it's very likely that cron will never support sub-minute granularity. Especially because, as MichaelT pointed out in the comments, use of sleep commands can easily create the desired behavior, without the need for changes to Cron itself.

share|improve this answer
    
Well, you probably could augment the minute field using e.g. :ss for seconds, but I wouldn't want to be the one to transparency test such a change, and that still doesn't resolve any of the other issues you mention. –  Michael Kjörling Jul 17 '13 at 11:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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