[Erm, I'm not really sure if that question is serious. Or does the OP really believe the crontab implementation used in Unbuntu is the only one there is and ever has been?]
Crontab is a data file for cron, a program like any other in unix or unixoide systems, implemented many times and in many ways.
At that point it might be important to keep in mind that things like program notifications if files have been changed and alike OS services are a rather new developmen.t
The original (Unix V7) cron implementation followed a very simple course of action:
- Read /usr/lib/crontab
- Determine if any job had to be started
- if yes, start that command
- Sleep for one minute
- Rinse and repeat
This is a rather robust approach. It didn't matter much if the crontab file got changed between two cycles (within a minute), as it was reread anyway. Problem is that this procedure is rather resource hungry. The file needs to be reread every minute, no matter if changed or not, it needed to be read every minute, no matter if there is a job scheduled or not.
With machines as small as back then these activities were already a nuisance, so people tried to optimize by changing the sequence:
- Read /usr/lib/crontab
- Determine if any job had to be started
- if yes, start that command
- Calculate how long until the next job to be started
- Sleep for as long as calculated
This reduced system load quite remarkably, cron load now scaled only linear with the number of jobs to be started. On the back side, any change to crontab was only recognized when the next scheduled event was to come. So when the change introduced a new jobstart before the last next to do, it was not executed - unless cron got killed and restarted.
This improvement came in especially handy as System V introduced per user crontab handling, as now dozends to hundreds of files had to be handled. W. Franta and Kurt Maly, who implemented the new cron, made it read all files and build an event list with an entry per file during startup. Like before cron went into sleep until the next event in that list was to be executed.
But unlike the previous step, they went full optimization and included not just the next event, but all for up to an hour. At the end of the list (he hour) an internal entry was inserted so schedule reread of all crontab files. Quite a great improvement - but re-synchronisation with changed file(s) would not happen for a long time.
To handle this they made cron react to SIGHUP, so a cron could be forced to reread all files with a simple kill -HUP.
This was ca. 1983. When again later the crontab files were moved from user home directories into a central spool directory, the crontab command referenced in above comment got introduced (~1986). It allowed a user to move his crontab file into that system directory and did send cron a message to reread all files.
This is the level next to all Unix derivatives from AIX to BSD copied.
Since then quite a lot different cron implementations have been made, most notably Vixie-cron, which IIRC was the base for cron used in various Linux distributions. Over the years it got a lot of improvements, like being informed of changes within the spool directory to enable automatic update.
Which cron is used in your system and how it works in detail is something you might have to lookup on your own.
