12 ms·

Cron checker

• ajmurmann 10y ago
  Looks like a more polished version of https://cronwtf.github.io https://cronwtf.github.io minus the awesome name and cat picture
  • faaabio1618 10y ago
    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 10y ago
  Looks great! I also find the other way around very convenient: http://thomseddon.github.io/cronstring/ http://thomseddon.github.io/cronstring/
• Animats 10y ago
  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.
  • agumonkey 10y ago
    Hourly.d
  • scrollaway 10y ago
    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 https://wiki.archlinux.org/index.php/Systemd/Timers#Example) is far more readable, and there's still a lot of room for improvement.
    • Spivak 10y ago
      Because it's not nearly as bad as people describe, it's extremely powerful, it's quite clever, and there's really not even a language to learn -- it's just regex/grep for timestamps. Cron ticks every minute and checks to see if any crontab entries match the current time, if so it runs the job. But standard regular expressions aren't well suited to the types of patterns people normally try to express which is why they use their own syntax.
    • audleman 10y ago
      Sure. Spend a focused 10 minutes to really try and understand them and you'll realize that a cron line is a perfectly concise and flexible syntax for creating scheduled time events. It even handles that crazy case where you want to run on a specific day of the week. Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Welcome to a special kind of hell. What I'm trying to say is there's complexity there and you'll be a better programmer if you embrace it. Unix programmers aren't in the habit of throwing out a working system because it's hard to grok, nor building something more complex then it needs to be. I took a look at your systemd timers link and it is a more complex syntax to create the same effect. From their own caveats section: > Complexity: to set up a timed job with systemd you create two files and run a couple systemctl commands. Compare that to adding a single line to a crontab.
      • scrollaway 10y ago
        > Spend a focused 10 minutes to really try and understand them I've spent the past years doing that. I do understand cron. I also strongly dislike it. You could build a thriving city within the bounds of the room there is for improvement. > It even handles that crazy case where you want to run on a specific day of the week. So does systemd's cron. Supporting "crazy cases" doesn't mean the syntax has to suck. > Cron lines may seem arcane at first, but then again have you ever tried to write code that was timezone aware? Yes... Re systemd: It's one example; it's not perfect, I wouldn't even call it good, but it's leagues ahead of cron in terms of UX already. Bonus: usage of the ini format means it's programmatically much easier to interact with the cronjob itself.
  • Spivak 10y ago
    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.
    • tdicola 10y ago
      That's the point though, if it's in a database you can have any number of awesome tools, text or GUI, to manipulate the state. And you don't need to reinvent the wheel to deal with atomic updates to the state, etc.
      • dsmithatx 10y ago
        Write a bash script to manage your cron and you can do the same thing in a terminal. Use http://freecode.com/projects/zenity http://freecode.com/projects/zenity or something similar for your new awesome GUI tool. I think for most people cron is simple enough to just google when they need the syntax. Although this crontab.guru site is 1000 time nicer than most google searches for help. I don't think a database would offer anything unless it was managing 1000's of cron servers. Flat text is fine and easier to parse than querying a database and adding a dependency. A database is a huge requirement to ask for to manage a few simple files.
      • jstimpfle 10y ago
        There is no need for a database. File updates are atomical. Editors rewrite the whole file. Also the tools argument just isn't true. A well designed plain text format is easier to parse with a one-off parser than with ugly one-off SQL queries. The reason that not many GUIs exist for plain text formats is that they are already designed to be easy to use. There are few cases where GUIs make sense. From the top of my head, the only configuration GUI I regularly use is firefox's. Not that it wouldn't be possible to come up with a clean plain text design that would be easier to use. Also most of the stuff is not represantable as relations. I'm looking forward to see how you encode a shell command in relations.
        • 10y ago
  • olgeni 10y ago
    Let's have a "registry".
    • IshKebab 10y ago
      Yes, KDE and Gnome both have registries. Just because Windows' registry is hard to manually edit doesn't mean they are a bad idea. Look at how much better Windows' GUI configuration tools are than anything on Linux. They all use the registry.
      • markdown 10y ago
        > Just because Windows' registry is hard to manually edit doesn't mean they are a bad idea. That's not the problem with Windows registry.
        • wfunction 10y ago
          >> Just because Windows' registry is hard to manually edit doesn't mean they are a bad idea. > That's not the problem with Windows registry. What is?
          • markdown 10y ago
            https://blog.codinghorror.com/was-the-windows-registry-a-good-idea/ https://blog.codinghorror.com/was-the-windows-registry-a-goo...
            • wfunction 10y ago
              Your link explicitly says you're wrong, though. Read it. It says: > My life would be a heck of a lot easier if per-application settings were stored in a place I could easily see them, manipulate them, and back them up. Like, say... in INI files. > The registry is opaque and binary. As much as I dislike the angle bracket tax, at least XML config files are reasonably human-readable, and they allow as many comments as you see fit. Now look at the comment you replied to: > Just because Windows' registry is hard to manually edit doesn't mean they are a bad idea. You said that's not the problem with the registry, but your own link says that's exactly the problem with the registry...
  • ckastner 10y ago
    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.
  • dingaling 10y ago
    > 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 https://www.sqlite.org/lockingv3.html
  • eli 10y ago
    The filesystem is a type of database. It isn't automatically better or worse than sqlite.
  • jstimpfle 10y ago
    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.
    • cel1ne 10y ago
      Not all databases follow a relational model with tables or schemas. I guess what he meant is that a key-value store would have some merits over files. Kinda like Window's registry.
      • jstimpfle 10y ago
        He explicitly mentioned sqlite. Key-value stores could not improve on that since RDBMS generalize key-value.
      • Zardoz84 10y ago
        Bad example. Windows registry is well know as a source of problems.
    • cma 10y ago
      A cron job kicks off that makes the whole system unresponsive, undergoing heavy swap (updatedb used to do this and ran every night on many default systems). Someone edits a cron file in the most common editor, vim. On many systems it doesn't do an atomic swap on save without extra configuration: http://stackoverflow.com/questions/13563627/how-does-vim-save-files http://stackoverflow.com/questions/13563627/how-does-vim-sav... Now maybe your unresponsive, undergoing swap, system misses a cron job that was present in both edits. Opps. I'm not sure this could really play out, but the approach definitely sounds firmly on the "worse is better" side of the scale.
  • lifthrasiir 10y ago
    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).
    • abpavel 10y ago
      > It is a problem of using files. In UNIX, everything is a file
      • lifthrasiir 10y ago
        If I were not clear enough, it is a problem of treating configuration files as like the runtime configuration. Not a problem of file formats (though some formats ease the job)---does this make sense?
      • dozzie 10y ago
        Oh, if only. Network interface is not a file. Process is not a file (though some of its metadata is accessible through different files under different unices). IPv4 routing entry is not a file. User account is not a file. Do you see a pattern?
        • abpavel 10y ago
          Network interface: /sys/class/net/<name> Process: /proc/<id>/ IPv4 Route: /proc/net/route User account: /etc/passwd
          • dozzie 10y ago
            OK, configure the network interface this way. Oh, you can't. So it is not a file, it just has some metadata exposed with a file interface. Create a process in the same manner. Oh, again you can't do that. What a shame. And with route and user account examples you confuse being a file and being a record in a file (which, couriously, is not a file itself).
  • edoceo 10y ago
    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.
  • xorcist 10y ago
    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 10y ago
  I leaerned more with one minute of this than all previous attempts at rtfm since 2002. Kudos http://crontab.guru/#*_5/6_*_*_* http://crontab.guru/#*_5/6_*_*_*
  • webreac 10y ago
    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, ...)
    • agumonkey 10y ago
      Fair enough, in my case I really couldn't skim and parse it.
• mangix 10y ago
  who uses cron when you have systemd anyway?
  • adontz 10y ago
    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.
  • perlgeek 10y ago
    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 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.
  • int0x80 10y ago
    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.
    • 10y ago
• lugus35 10y ago
  It would be nice to have the inverse: write in plain english what you want and it gives you the crontab line.
• gourneau 10y ago
  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/ http://rundeck.org/ * Stackstorm https://docs.stackstorm.com https://docs.stackstorm.com * ndscheduler https://github.com/Nextdoor/ndscheduler https://github.com/Nextdoor/ndscheduler
• taspeotis 10y ago
  5 4 W * * Really gave Chrome some grief.
  • 0xmohit 10y ago
    > 5 4 W * * > Really gave Chrome some grief. You are evil. It also gave Firefox a lot of grief. CPU usage shot to 100%.
    • Bromskloss 10y ago
      Pff. My Firefox CPU usage is always at 100%.
      • ComodoHacker 10y ago
        Buggy addon perhaps?
  • kowdermeister 10y ago
    What does that expression mean?
• 0xmohit 10y ago
  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/ http://crontab-generator.org/ [1] https://news.ycombinator.com/item?id=12105516 https://news.ycombinator.com/item?id=12105516 [2] https://en.wikipedia.org/wiki/Cron https://en.wikipedia.org/wiki/Cron
• yoavm 10y ago
  what about @reboot ?
  • kseistrup 10y ago
    Read tip number 5: http://crontab.guru/tips.html http://crontab.guru/tips.html
  • efiala 10y ago
    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 :)
• Pamar 10y ago
  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 https://news.ycombinator.com/item?id=12084455
• deleted 10y ago
  [deleted]
• joelthelion 10y ago
  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 10y ago
    > 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-the-environment-cron-executes-a-script-with http://stackoverflow.com/questions/2135478/how-to-simulate-t...
    • cmiles74 10y ago
      Running a cron job that writes out it's environment and then running the job I'm testing in that environment has always worked pretty well for me. A hassle, but I've had good luck.
      • therein 10y ago
        I was about to suggest the same. Just have your cronjob dump its environment for you so that you can simulate it more accurately.
  • CraigJPerry 10y ago
    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 10y ago
    This. Simulating cron's is the most frustrating thing I do in my workday.
  • userbinator 10y ago
    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.
• CraigJPerry 10y ago
  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
• fideloper 10y ago
  Can anyone find (confirm) flaws in it? For example, this gives me the same result for 0/5 * * * * as it does for */5 * * * *
• krick 10y ago
  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.
  • pekeler 10y ago
    You're either a lousy web developer, bad at estimates, or I totally need to hire you. Hmm :)
  • michaelmrose 10y ago
    We await your efforts. Please detail the advantages your system will have over existing cron implementations and put up a kickstarter.
• krzrak 10y ago
  "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.” :)
• boot13 10y ago
  I love this. Thank you.
• unchaotic 10y ago
  Some other random ones that I've used in the past : http://www.cronmaker.com/ http://www.cronmaker.com/ http://crontab-generator.org/ http://crontab-generator.org/ http://www.openjs.com/scripts/jslibrary/demos/crontab.php http://www.openjs.com/scripts/jslibrary/demos/crontab.php http://htmlminifiers.com/cron-maker.php http://htmlminifiers.com/cron-maker.php http://cron.nmonitoring.com/cron-generator.html http://cron.nmonitoring.com/cron-generator.html https://crontranslator.appspot.com/ https://crontranslator.appspot.com/ http://cron.schlitt.info/ http://cron.schlitt.info/