Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement crontabs #626

garlick opened this Issue Apr 4, 2016 · 6 comments


None yet
2 participants
Copy link

garlick commented Apr 4, 2016

An early design idea for Flux was to implement "crontabs" or jobs that are run periodically for some housekeeping task the user wants.

As discussed in #604, to reduce content storage requirements, thelwj directory which is flat and grows without bound, needs to be pruned in order to avoid exponential KVS growth. (The issue is that for each addition to this directory, a new content object is created that is slightly larger than the last). We can mitigate this by periodically pruning the directory, either by removing old jobs, or by moving them to a non-flat hierarchy.

Crontabs seem like an easy way to handle this sort of use case.

Initially cron jobs could run outside of regular job scheduling, and could simply be launched as sub-processes of the rank 0 broker (launched in parallel with initial program). We could mimic crontab(1) behavior, e.g.

To submit a cron job:

flux crontab <crontab_file

To list crontab

flux crontab -l

Crontabs could use the crontab(5) format e.g.

minutes:hour:day-of-month:month:day-of-week command ...

With ranges, lists, and asterisk handled.

Also, similar to @reboot, we might add special @heartbeat, @jobcomplete, etc..

I propose we do this or something like it in the near term to handle the KVS pruning use case. Feedback welcome on the design sketch.


This comment has been minimized.

Copy link

grondo commented Apr 4, 2016

It feels like the crontab(5) approach is a bit outdated nowadays, I wonder if we could get some design ideas from replacements like chrony, anacron, and even chronos? I actually haven't looked at these in awhile so there might be nothing there.

I'd also prefer a named list of scheduled items rather than a static crontab, though a file that lists a large set of scheduled work is a good idea for use from an rc1 script. With named scheduled items, it would be easier to present a "status" command that listed the cron jobs and when they were last run, last exit status, etc. (I think I saw this kind of interface in chronos)


This comment has been minimized.

Copy link

grondo commented Apr 4, 2016

Chronos uses ISO8601 date-times and intervals. I'm not sure if ISO8601 interval definitions are any easier to grok than crontab entries.

What if the base flux cron protocol was JSON and we just split the repeating interval into its components in the json blob, e.g.

cron-entry {
    "name":         string     ; Optional (?) name for entry
    "command":  string     ; Command to run
    "on_year":     integer 
    "on_month":  integer 
    "on_day":      integer
    "on_hour":     integer
    "on_minute": integer  
    "on_dow":     integer    ; Run only on day of week (0, 6)
    "on_event":   string      ; Run only at event

The command to generate these requests could use ISO8601 datetimes at first, but later could be extended to take more user friendly input like

flux cron every 10m command
flux cron every @heartbeat command
flux cron at 2016-06-01

In fact, it would be kind of nice if every and at were subcommands of a flux run command.

There should also be commands to list and cancel existing entries, e.g.

$ flux cron ls
ID          NAME    SCHEDULE                                   STATUS
1         cleanup    R/2016-04-01-12:00:00/PT24H               ok
2        jobcheck    @jobcomplete                              ok

$ flux cron rm 1
Deleted cron job 1

This comment has been minimized.

Copy link
Member Author

garlick commented Apr 4, 2016

Looks nice!

@garlick garlick added this to the release 0.3.0 milestone Apr 13, 2016

@grondo grondo modified the milestones: release 0.4.0, release 0.3.0 Apr 26, 2016


This comment has been minimized.

Copy link

grondo commented May 2, 2016

Forgot to reference this Issue in PR #659.

In that PR a cron entry has JSON of a form more like:

 "name": string,
 "command": string,
 "repeat": integer,
 "task-history-count": integer,
 "type": string,
 "args": json-object

Where args is a JSON object describing the type-specific args for cron type type.

E.g. interval type has simply a double "interval" argument in seconds, "event"
has a "topic" string argument, and "nth" integer argument, etc.

grondo added a commit to grondo/flux-core that referenced this issue May 7, 2016

modules/cron: Initial version
Initial version of a cron-like service for Flux.

The flux cron module maintains a list of cron entries which
track and execute tasks (executed under sh -c "command") based on
a set of cron entry types. Current cron entry types supported
are "interval" (run once every interval), and "event" (run once
every Nth event).

This service is exported via a "cron.*" service. Current methods
supported are cron.create,list,stop,start, and destroy.

Fixes flux-framework#626

This comment has been minimized.

Copy link
Member Author

garlick commented May 31, 2016

This was implemented in pr #659

@garlick garlick closed this May 31, 2016


This comment has been minimized.

Copy link

grondo commented May 31, 2016

Thanks I was going to ask if this one met your criteria without actually implementing traditional crontab interface

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.