Cron checker

[Animats]

This is why the UNIX approach of using flat text files for dynamic information is obsolete. It seems so simple to have a text file. But then you need an editor, a locking system, access control, and a checker. And probably something to remove orphaned lock files and detect corrupted data.

Those are all database functions. In UNIX/Linux, each configuration file has its own mechanism for all that. They're all inferior to SQLite.

[jstimpfle]

Crontab is an excellent example of situations where text files are superior. You are welcome to try to design a database schema that is safer or easier to use.

Most of the things living under /etc are not databases. crontab certainly isn't:

- Only a single "table" (no table-relations)

- No standard database type exists for columns (how would you model the scheduling as database types, how would you model the shell command as database types, if not simply as sanitized strings)

So you can't get integrity for free. Need a custom parser and some integrity checks. Not so difficult (yes, cron will give instant feedback for the unlikely case that you did something wrong)

Re: editor, locking, access control:

I have an editor and prefer it to writing SQL DML any day.

File updates (rename(2)) are atomic, so no need for additional locking. And even if there is some broken tool writing to the old file instead of rename, the chances of that being simultaneous with a parse are microscopic. Don't overdesign. (there are many more things that can go wrong in a system that you can't possibly design out. Live with it).

Access control: Standard file permission modes are just fine. More complex permission model would be a serious overdesign. You can get granularity by using separate crontabs.

Checker: Never needed an additional tool to format the meaning as human-readable text. The syntax is a bit ugly but quite easy to remember and use.

[ckastner]

This comment doesn't make sense to me at all.

Editor: of course you need some way to input data, and an editor is the simplest interface. You need to generate SQL to store data in SQLite and that's certainly not simpler.

Locking system: the OS/filesystem can provide this just as well as a database can.

Access control: same answer

Checker: input needs to be validated for its intended task and SQLite won't magically make this requirement disappear.

[edoceo]

Who edits crontab by opening in the editor directly? Using `crontab -e` is what the manual says to do (cron, fcron, dcron)

Or did we not read the manual, then complain about broken stuff and follow that with an over-enginered "solution" to a problem that didn't exist.

[Spivak]

You probably wouldn't want to use text files for actual database information, but they're perfect for code and configuration.

The syntax of cron isn't the most intuitive but it's powerful and would make even less sense in a database.

[scrollaway]

Can someone explain to me how crontabs, and cron syntax, are still so popular and one of very few options available?

It's not like crontabs are written all the time. They don't need to be so terse. They shouldn't require learning a language... they shouldn't require a cron.guru website. Systemd timer syntax (https://wiki.archlinux.org/index.php/Systemd/Timers#Example) is far more readable, and there's still a lot of room for improvement.

[lifthrasiir]

No, it is NOT a problem of using flat files. It is a problem of using files. The files are the serialized initial values for the run-time configuration, which may or may not be changed. SQLite is no superior to flat files in that, and in fact, can be damaging if the user managed to break the invariant and the invariant is not checked.

The configuration system absolutely demands the locking system (to alter it) and the checker (to correctly check if it is correct before the changes are ever committed). SQLite can provide some of them, but not all---most importantly, SQLite's locking system is independent of the runtime configuration which requires separate locking system (however rudimentary).

[olgeni]

Let's have a "registry".

[eli]

The filesystem is a type of database. It isn't automatically better or worse than sqlite.

[dingaling]

> They're all inferior to SQLite

Which itself has all sorts of complications around locking. Can't write when another process has read-only lock, for example:

https://www.sqlite.org/lockingv3.html

[xorcist]

Yes, text files are useless. This "programming" thing will never take off. It would require an editor and code checking. Totally inferior to SQLite.

Makes sense.

[agumonkey]

Hourly.d

[joelthelion]

What I'd like is a way to check that the command will run properly. Waiting for one minute to test is not productive at all. And no, testing in your shell won't do, since cron runs in a particular environment.

[chrisan]

> And no, testing in your shell won't do, since cron runs in a particular environment.

Have you tried any of these answers?

http://stackoverflow.com/questions/2135478/how-to-simulate-t...

[CraigJPerry]

Different crons have different rules but assuming the ubiquitous vixie cron:

    env - HOME=$HOME LOGNAME=$LOGNAME sh -c 'command line'

Home, shell and logname are the only 3 variables guaranteed to be set.

[taphangum]

This. Simulating cron's is the most frustrating thing I do in my workday.

[userbinator]

Waiting for one minute to test is not productive at all.

You could simply find something else to do for a minute, like rechecking that the other pieces of the system are setup correctly as well.

[ajmurmann]

Looks like a more polished version of https://cronwtf.github.io minus the awesome name and cat picture

[faaabio1618]

But more correct:

cronwtf:

0 0 1 1 0 COMMAND Runs `COMMAND` at minute :00, on hour 0, on day 1, in Feb, on Sun.<-- NO!

crontab:

0 0 1 1 0 At 00:00 on the 1st and every Sun in Jan. <-- CORRECT

[thomseddon]

Looks great! I also find the other way around very convenient: http://thomseddon.github.io/cronstring/

[taspeotis]

    5 4 W * *

Really gave Chrome some grief.

[0xmohit]

> 5 4 W * *

> Really gave Chrome some grief.

You are evil.

It also gave Firefox a lot of grief. CPU usage shot to 100%.

[kowdermeister]

What does that expression mean?

[0xmohit]

Crontab generator [0] is a good alternative that doesn't feature broken JS [1]. Moreover, the example and configuration page on the wikipedia page [2] are clear enough.

[0] http://crontab-generator.org/

[1] https://news.ycombinator.com/item?id=12105516

[2] https://en.wikipedia.org/wiki/Cron

[unchaotic]

Some other random ones that I've used in the past :

http://www.cronmaker.com/

http://crontab-generator.org/

http://www.openjs.com/scripts/jslibrary/demos/crontab.php

http://htmlminifiers.com/cron-maker.php

http://cron.nmonitoring.com/cron-generator.html

https://crontranslator.appspot.com/

http://cron.schlitt.info/

[agumonkey]

I leaerned more with one minute of this than all previous attempts at rtfm since 2002. Kudos

http://crontab.guru/#*_5/6_*_*_*

[webreac]

As a non english native, the man page of cron is far more complete and easy to read than many other pages (find, tar, bash, ...)

[krzrak]

"15 14 1/2 2 *" -> “At 14:15 on the 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29 and 31st in Feb.” :)

[lugus35]

It would be nice to have the inverse: write in plain english what you want and it gives you the crontab line.

[Pamar]

Hopefully this will attract lots of cron experts. systemd experts are fine too... I have a question for you all: https://news.ycombinator.com/item?id=12084455

[krick]

Why just not replace cron with something a bit more flexible in terms of settings and config formats? Seriously, I guess time spent on making this website should be coparable with rewriting cron — it's not like cron is a complicated piece of software.

[michaelmrose]

We await your efforts. Please detail the advantages your system will have over existing cron implementations and put up a kickstarter.

[pekeler]

You're either a lousy web developer, bad at estimates, or I totally need to hire you. Hmm :)

[fideloper]

Can anyone find (confirm) flaws in it? For example, this gives me the same result for

    0/5 * * * *

as it does for

    */5 * * * *

[gourneau]

This is a super great tool.

If any of y'all are looking for a more modern cron replacement for running periodic tasks with a nice web uis here are a few other options:

* Rundeck http://rundeck.org/ * Stackstorm https://docs.stackstorm.com * ndscheduler https://github.com/Nextdoor/ndscheduler

[CraigJPerry]

Heh it even models the weird behavior you get when you specify day of month AND day of week.

All other fields are AND together, these two are OR

[boot13]

I love this. Thank you.

[mangix]

who uses cron when you have systemd anyway?

[perlgeek]

Not everybody has systemd. The BSDs don't (iirc), and for example we are stuck with some Debian Wheezy host at $work, which don't come with systemd either.

Also, lots of operators have decades of experience with cron, and don't want to give up on that easily.

[Update] After reading https://wiki.archlinux.org/index.php/Systemd/Timers I see two more reasons

* You don't have to write a service file to use cron jobs, which makes ad-hoc tasks much easier

* Sending mails is the default for cron, which requires extra work with systemd.

[adontz]

A lot of people who are familiar with cron already, but not with systemd.

But, to be honest, writing crontab is easier task, systemd timers are not more intuitive than cron when you write them, i.e. I personally still look in documentation for various systemd options, but are IMHO much easier to read and more powerful, and have great "systemctl list-timers" view, but unfortunately not superset of crontab options. That's probably the second reason to still use crontab.

[int0x80]

So, obviously systemd has also taken over crontab? My god ... Really this is sick. I've to fight systemd to do some dead simple init.d custom services and it was awful. Even the process resource limits had to be setup in the sytemd config files.

I like /etc/crontab. It is a simple text file. Nothing magic. Standard. Works every time. Well known by everybody. Works on a lot of UNIXes, old Linux systems etc.

I don't want no new complexity and a new way to do things every 6 months. What I hate most is that all this is pushed through our throats no matter what we want. FFS.

EDIT: BTW, I think luckily, /etc/crontab at least currently still works on Ubuntu Server 16.04 (what I've tried). I think this is the way to go. If you want to use some new features (systemd) you can opt-in. But don't break old stuff please.

[yoavm]

what about @reboot ?

[kseistrup]

Read tip number 5: http://crontab.guru/tips.html

[efiala]

yeah I agree with Tip #5 at least for a server environment, there are better ways to run things on reboot that need to run on reboot, although for those in the anacron camp, I suppose this level of randomness would appeal / appear entirely reasonable :)