First of all, I understand that the problem cron solves is a hard one but come on, it's been many years now without much progress. At least not in the usability field of cron jobs. Secondly, I don't know of an operating system that does this better. Perhaps there is one. All I'm saying here is that this aspect of Linux sucks. The issues I have with cron are:

Beef number 1 Is it root, user1 or user2 running a crontab job? I'll have to su into each suspected user and run crontab -l. Granted, some jobs require root access and others don't but it nevertheless makes it hard to find the configured jobs when maintaining someones server.

Beef number 2 Even though they do such a similar thing, it feels like /etc/cron.* is a different battlefield from crontab. Why can't this all be in one coherent place?

Beef number 3 The crontab syntax. How difficult would it be to allow an interface to accept user input as "every 10 minutes" or "01.30 every day"?

Beef number 4 With there being 12 different ways (sarcasm) to write cron job scripts there's no coherent place to collect all log and errors that happen from cron. Couldn't it be default to always write to /var/log/cron/access.log and all executions that cause a write to stderr could append to /var/log/cron/error.log

I don't think Anacron would make me any happier since the problem Anacron solves was not one of the problems I listed above. And lastly, I wouldn't be surprised if there's a semi-abandoned Open Source project on SourceForge that is user friendly but what I'm after is something to get into stock Linux. Kind of like apt/aptitude/dselect is for dpkg maybe?

Comments

Post your own comment
Noah Gift

I agree with you. cron sucks. There was talk on the supervisord list of making a Python cron that was built into supervisor, but no one like it.

Personally, I think it would be cool to write a Python crond :)

Abdoulaye Siby

Why are you guys complaining about this? And most importantly, who are you complaining to? One of the most important aspect of Open Source is that anyone can step in and improve upon an existing code. So why don't you put down you weapons, and pull out your keyboards to create something better? It can even be something as simpler as a wrapper application or an application that will edit existing cron jobs or that will list all cron jobs by looping into all the users in the linux box.

Cheers

Julio Schwarzbeck (Speedbird)

I agree that cron may not be the most beautiful chick at the party, but here's a suggestion that will make it easier, just add a maintenance account in the server and give it sudo for whatever task you want to run, in any case, within a server, how many users are supposed to run cron jobs anyway? (at least the jobs regarding system maintenance, etc). Just my 2 cents, cheers and nice blog Peter

Patrick May

Beef #1 (at least for rhel / centos):
sudo grep -r 'beef' /var/spool/cron

ksamuel

This is why in a pure Python env celerybeat + supervisord does the job much better:

CELERYBEAT_SCHEDULE = {
    # Executes every Monday morning at 7:30 A.M
    "every-monday-morning": {
        "task": "tasks.add",
        "schedule": crontab(hour=7, minute=30, day_of_week=1),
        "args": (16, 16),
    },
}

It's pure python, it runs python fonctions and it's explicit. But it does require additional setup.

http://ask.github.com/celery/userguide/periodic-tasks.html

Beefsteak

I realize this post is very old but there's a new solution in town as of 2022: xcron.

Beef 1: ./xcrontab get-schedules

Beef 2: xcron manages the xcrontabs itself.

Beef 3: The default xcrontab template has the allowed formats in a couple of comments. Really though, the schedule definition format for cron is actually quite elegant. Have you seen what you have to do on Windows to schedule a task? Also, just use: ./xcrontab get-schedules

Beef 4: xcron gathers error/output logs automatically. Get last run output: ./xcrontab get-output Or, better yet, get last run that failed output: ./xcrontab get-errors

xcron solves those beefs and more. Mmm...steak.

Your email will never ever be published.

Related posts