UniCron is intended to be a complete, fully featured and highly flexible Unix style cron daemon or system scheduler. In addition to this it is meant to make system administration not only more powerful, but easier, simpler and thus less error prone too. And what's more it'll save on system resources to boot due to it's rather clever timing system.
Don't really know yet. Any ideas?
UniCron's file format is so intelligent I think it deserves some kudos of it's own.
At the centre of the UniCron's philosophy is the idea of triggers. Triggers are things which can be started, and which can fire, and when they fire, you can specify what they do. Triggers can either loop - that is continue going having been started (for ever of for a set period or number of times), or go once only. The difference in time between a trigger being started and the trigger firing (and the gap between two sequential firings) is specified as part of the trigger configuration. This can be specified in a number of ways not least a specific amount of time (e.g. "5 minutes", "4 days"), a time in relation to a bigger unit (e.g. "tuesday (of the week)", "April (of the year)", "4 pm (of the day)"), pseudo lengths - i.e. a specific length of time that may not actually be the same for any two firings ("2 months", "1 year").
The magic is, of course that a trigger may start other sub-triggers when it fires --- ad infinitum. Here are a few examples to wet your appetite:
<loop when="2am">
<event run="updatedb"/>
</loop>
<loop every="2 days" until="april">
<wait until="2am">
<event run="updatedb"/>
</wait>
</loop>
<loop every="week">
<loop when="mon,tue,wed,thu,fri">
<loop when="7am,7pm">
<event run="syncdb"/>
</loop>
</loop>
<loop when="12pm">
<event run="syncdb"/>
</loop>
</loop>
<loop every="3 months">
<wait until="sun 3.30am">
<event run="backup"/>
<loop for="7 hours">
<event run="monitor_backup"/>
</loop>
</wait>
</loop>
As you should be able to appreciate, the specification format is extremely flexible, maintainable and generally readable. This was always the primary aim, however such aspects as system resources were taken very seriously indeed through out the prolonged design stage of this project.
CPU usage is very low due to the clever design. Unlike other schedulers, this program never polls at all. It runs in several threads - the worst-case being one thread for every loop/wait tag in the specification file. Each thread spends (approximately) 99.9999% of the time in the sleep command. When it's not sleeping it is either firing (i.e. executing a command) or working how long it should sleep for.
It only works out how long it should sleep for each time it fires, and thus even if a thread fired every minute and the working out took 100000 instructions (a large estimate), it would be asleep for approximately 99.9999% of the time on a 1GHz machine. And that's pretty much worst-case. Most firings would take place far less often rendering the CPU impact trace. Polling-based schedulers, of course, decrease in overall efficiency as the frequency goes down (since they waste more time polling).
The resident memory size is quite large at around 10 megs for a scheduler, however in fairness, most of this is the libstdc++ shared library and would probably be loaded anyway. The actual amount of memory taken is more like 1.2MB. This is basicly constant and doesn't change much for a given number of threads. In any case memory is cheap and downtime caused by program failure or mistakes in the cron specification or lack of flexibility of the cron specificer isn't.
The technology and design is there, and the theory works out - but don't just take my word for it - try it out yourself!
UniCron is so far quite young in it's life span. It was designed from the ground up as an application that must run in a mission critical environment and thus the design is highly robust. The timing dynamics have been thoroughly and somewhat near-exhaustively tested to great success. It clearly performs floorlessly and to specification in even the most complex situations I could throw at it, including online restructuring of very complex timing trees.
Theoretically, therefore it should deliver and deliver well. However there is, of course no warranty, so you might want to check over the source code and convince yourself that it does indeed work as I say before you rely upon it too much! My main concern is getting it beta-tested and getting real life reports of it working. Getting all the needed Unix features ironed out would help also. Any and all reports would be highly welcome and I will try my best to fix or help with any problems.
This program is Free software. That means it is available for distribution under the GNU General Public Licence. This also means that the software comes with no guarantees to work. Neither I nor anyone else will be liable for any damages caused in using (or misusing) it. Essentially, as with all software nowadays, use at your own risk. (That's not to say it won't work of course ;)
You can contact me, Gav Wood, at gav.a.kde...org.