cron-job.org Open Source project
databasecontains the MySQL database structure.
chronosis cron-job.org's cron job execution daemon and is responsible for fetching the jobs.
protocolcontains the interface definitions for interaction between system nodes.
webcontains the web interface (coming soon)
chronos checks the MySQL database every minute to collect all jobs to execute. For every minute, a thread is spawned which processes all the jobs. Actual HTTP fetching is done using the excellent CURL multi library with libev as library used to provide the event loop. Together with the c-ares resolver this allows for thousands of parallel HTTP requests.
cron-job.org supports storing the job results for the user's convenience. This can quickly lead to I/O bottlenecks when storing the result data in a MySQL database. (Which also has the downside that cleaning up old entries is extremely expensive.) To solve this issue, chronos stores the results in per-user per-day SQLite databases. Cleaning up old entries is as easy as deleting the corresponding day's databases.
The whole software is optimized on performance rather than on data integrity, i.e. when your server crashes or you have a power outage / hardware defect, the job history is most likely lost. Since this is volatile data anyway, it's not considered a big issue.
chronoscan now run on multiple nodes. Each node requires an own MySQL server/database and stores its own jobs. The host running the web interface also manages the user database and an association between job and node. The web interface can create, delete, update and fetch jobs and job logs from the particular node via a Thrift-based protocol defined in the
In order to build chronos, you need development files of: * curl (preferably with c-ares as resolver and libidn2 for IDN support) * libev * mysqlclient * sqlite3 * thrift (compiler and libthrift)
To build, you need a C++14 compiler and cmake.
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
chronos.cfgaccording to your system (especially add your MySQL login)
ulimit -n 65536or similar first.
innodb_flush_method=O_DIRECTin your MySQL config for best performance. Otherwise the update thread (which is responsible for storing the job resuls) might lag behind the actual job executions quite soon.