Awesome

<html> <head> <title>kubjas - daemon to execute scheduled commands</title> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <link rev="made" href="mailto:root@localhost" /> </head> <body style="background-color: white">  <div name="index"> <a name="__index__"></a> <ul>

<li><a href="#name">NAME</a></li>
<li><a href="#synopsis">SYNOPSIS</a></li>
<li><a href="#description">DESCRIPTION</a></li>
<li><a href="#configuration">CONFIGURATION</a></li>
<li><a href="#signals">SIGNALS</a></li>
<li><a href="#see_also">SEE ALSO</a></li>
<li><a href="#files">FILES</a></li>
<li><a href="#author">AUTHOR</a></li>
<li><a href="#copyright">COPYRIGHT</a></li>
<li><a href="#date">DATE</a></li>

</ul> <hr name="index" /> </div>  <hr /> <h1><a name="name">NAME</a></h1> kubjas - (cron like) daemon to execute scheduled commands <hr /> <h1><a name="synopsis">SYNOPSIS</a></h1> kubjas.pl [--background] [--conf_file /etc/kubjas.conf] [--log_file /path/kubjas.log] [--pid_file /path/kubjas.pid] <hr /> <h1><a name="description">DESCRIPTION</a></h1> Kubjas is periodic job scheduler that operates with minimum 1 second intervals. Kubjas is not another cron daemon. Kubjas does not start programs at certain time but at specified intervals. Kubjas also includes Time::Period filter. You can configure interval and period combinations that act like crontab. Kubjas measures executed job running times and log it when job exits. Measurements are in milliseconds resolution. Kubjas configuration is standard INI file format. You can have multiple configuration files at same time. Main configuration is /etc/kubjas.conf and /etc/kubjas.d/ directory is for additional configurations. Each job can have her own config file. You can force configuration reload with HUP signal. <hr /> <h1><a name="configuration">CONFIGURATION</a></h1> <dl> <dt><a name="example_conf" class="item">example.conf</a></dt> <dd> <pre> [*] notify-failure = 127.0.0.1:send_failure_notify</pre> <pre> [date-job] cmdline = date +"%H:%M" > /var/tmp/date.txt interval = 60 user = nobody group = nogroup notify-success = 192.168.1.27:catch-signals</pre> <pre> [catch-signals] cmdline = /usr/local/bin/catch-signals.pl interval = success-message signal = USR2</pre> <pre> [readfile] cmdline = /usr/local/bin/readfile.sh interval = onchange watch = /var/tmp/date.txt output = /tmp/date.log user = nobody group = nogroup</pre> <pre> [very-shy-job] cmdline = /usr/local/bin/shy.sh interval = 10-20 period = wday {1 3 5 7} min {0-29}, wday {2 4 6} min {30-59} depends = catch-signals conflicts = date-job nice = 1 ionice = 1</pre> <pre> [send_failure_notify] cmdline = send_failure_notify.sh %host% %job% %notify% interval = failure-message output = none</pre> </dd> <dt><a name="job_name" class="item">job-name</a></dt> <dd> [job-name] is the INI file section. Job names must be unique. Special section name [*] sets default params that will be used with all jobs defined at the same configuration file. Named job sections overwrite default params. </dd> <dt><a name="cmdline" class="item">cmdline</a></dt> <dd> Parameter cmdline define executable program with parameters <pre> cmdline = perl /usr/local/bin/catch-signals.pl cmdline = catch-signals.pl</pre> these lines are equivalent if PATH environment variable includes /usr/local/bin and /usr/bin Secure way is usage of full path names :-) In combination with watch and notify you can add some template parameters that will be filled with info at execution time. <pre> cmdline = send_alert.sh %host% %job% %notify%</pre> Template name %host% will replaced with hostname where notify origins. Template name %job% will replaced with job-name which sends the notify. Template name %notify% will replaced with notify message which can be start-message, success-message, failure-message or filename that inotify watch discovered IN_CLOSE_WRITE event. </dd> <dt><a name="output" class="item">output</a></dt> <dd> Default is passthrough and all jobs STDOUT and/or STDERR stream will passed through to kubjas STDOUT or log file (if defined with command line options). Value none disables all output and is "cmdline 2>&1 >/dev/null" equivalent. <pre> output = none</pre> If param output value is filename then kubjas opens the file with append atributes and jobs STDOUT and STDERR will be forwarded to this file. <pre> output = /var/log/job-name.log</pre> </dd> <dt><a name="interval" class="item">interval</a></dt> <dd> Specifies time in seconds between job last start. It is the minimum delay between the different runs. Actual delay may be longer if other conditions prevent running. Null (0) means that job is disabled. Interval can also be defined as randomized range. Example starts job every 20 to 30 seconds. <pre> interval = 20-30</pre> There are also four special (non numeric) intervals that activated only by outside events: onchange, start-message, success-message, failure-message <pre> interval = onchange interval = failure-message</pre> onchange works with watch parameter. see watch start-message, success-message, failure-message will trigger job execution then notify message arrives. see notify-start </dd> <dt><a name="period" class="item">period</a></dt> <dd> Parameter determines if a given time falls within a given period. Kubjas executes job only if period is met. Period is optional param. Theoretically you can emulate crontab with interval and period combination. Example job will be run only once a day at 0:00 midnight <pre> interval = 60 period = hr {12am} min {0}</pre> See also man Time::Period. A sub-period is of the form <pre> scale {range [range ...]} [scale {range [range ...]}]</pre> Scale must be one of nine different scales (or their equivalent codes): <pre> Scale | Scale | Valid Range Values | Code | **************************************************************** year | yr | n where n is an integer 0<=n<=99 or n>=1970 month | mo | 1-12 or jan, feb, mar, apr, may, jun, jul, | | aug, sep, oct, nov, dec week | wk | 1-6 yday | yd | 1-365 mday | md | 1-31 wday | wd | 1-7 or su, mo, tu, we, th, fr, sa hour | hr | 0-23 or 12am 1am-11am 12noon 12pm 1pm-11pm minute | min | 0-59 second | sec | 0-59</pre> crontab comparison [1] <pre> */5 * * * * nobody cmdline</pre> <pre> interval = 300 user = nobody</pre> crontab comparison [2] <pre> 0 0 * * * 7 cmdline</pre> <pre> interval = 60 period = wd {su} hr {12am} min {0}</pre> or <pre> interval = 1 period = wd {7} hr {0} min {0} sec {0}</pre> crontab comparison [3] <pre> # run at 2:15pm on the first of every month 15 14 1 * * cmdline</pre> <pre> period = md {1} hr {14} min {15} sec {0}</pre> crontab comparison [4] <pre> # run at 10 pm on weekdays 0 22 * * 1-5 cmdline</pre> <pre> period = wd {Mon-Fri} hr {22} min {0} sec {0}</pre> </dd> <dt><a name="user" class="item">user</a></dt> <dd> Run jobs as given user. Kubjas resolves user UID </dd> <dt><a name="group" class="item">group</a></dt> <dd> Run jobs as given group. Kubjas resolves group GID. </dd> <dt><a name="watch" class="item">watch</a></dt> <dd> Kubjas is monitoring file system events with Linux inotify API if you specify list of files and directories to watch. One job can have many watch parameters. Kubjas monitors IN_CLOSE_WRITE events eg. change of file. Example: <pre> watch = /tmp</pre> Will trigger job start always the /tmp directory changes. Only one job at a time. </dd> <dt><a name="notify_start_notify_success_notify_failure" class="item">notify-start notify-success notify-failure</a></dt> <dd> Kubjas will notify any other local or remote jobs then current job starts and ends. Other job configuration specifies then it runs at start-message or success-message. Example you can define two jobs that run after each other. <pre> [job-one] notify-success = 127.0.0.1:job-two interval = success-message</pre> <pre> [job-two] notify-success = 127.0.0.1:job-one interval = success-message</pre> Then job exits with return code other than 0 (with some kind of failure) then you can send failure notify to job that fix it or notifies administrator. <pre> [failure-handler] cmdline = /usr/local/bin/send_email_to_admin.sh interval = failure-message</pre> </dd> <dt><a name="conflicts" class="item">conflicts</a></dt> <dd> This job will only run if no specified jobs are running. Example you can have CPU intensive jobs that runs only then other similar jobs not running. <pre> [hard-work] conflicts = cpu-work1 conflicts = hard-work2</pre> You can have multiple conflicts params. conflicts param can be special wildcard value that rule out any jobs defined at the same configuration file. <pre> [spcial-job] conflicts = *</pre> </dd> <dt><a name="depends" class="item">depends</a></dt> <dd> This job will only run if depends are met. If specified jobs allready running. Example you can run periodic jobs only if other job is running. <pre> depends = other-job</pre> You can have multiple depends params. depends param can be special wildcard value that require all other jobs to be running that are defined at the same configuration file. <pre> [ping] depends = *</pre> </dd> <dt><a name="nice_ionice" class="item">nice ionice</a></dt> <dd> Decrease executed job CPU and I/O scheduler priority. <pre> nice = 1 ionice = 1</pre> Will do "renice +10" and "ionice -c 3" </dd> <dt><a name="signal" class="item">signal</a></dt> <dd> Combined with interval special cases you can send UNIX signals to running jobs if notify event happen. <pre> [catch-signals] interval = onchange watch = /tmp/date.txt signal = USR2</pre> </dd> </dl> <hr /> <h1><a name="signals">SIGNALS</a></h1> Kubjas handles following signals: <dl> <dt><a name="hup" class="item">HUP</a></dt> <dd> If you send HUP signal then kubjas reloads configuration. Example: kill -HUP <PID> This does not affect running jobs. </dd> <dt><a name="usr1" class="item">USR1</a></dt> <dd> If you send USR1 signal then kubjas prints active jobs to log. Example: kill -USR1 <PID> Wed Jun 25 15:08:05 2014 running (date-job readfile) </dd> <dt><a name="usr2" class="item">USR2</a></dt> <dd> If you send USR2 signal then kubjas stops schedule new jobs. Example: kill -USR2 <PID> When you need server maintenance then it is very handy feature. After you signalled USR2 you can watch log and wait all jobs to be completed before shutdown or restart without breaking any running jobs. <PID> == kubjas PID for example 1234 </dd> </dl> <hr /> <h1><a name="see_also">SEE ALSO</a></h1> Time::Period(3pm) <code>inotify(7)</code> <hr /> <h1><a name="files">FILES</a></h1> <pre> /etc/kubjas.conf /etc/kubjas.d/</pre> <hr /> <h1><a name="author">AUTHOR</a></h1> <pre> Kain Kalju <kain@kalju.com></pre> <hr /> <h1><a name="copyright">COPYRIGHT</a></h1> <pre> Copyright (c) 2014 FlyCom OU. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.</pre> <hr /> <h1><a name="date">DATE</a></h1> June 25, 2014 </body> </html>