Hacker News Reader

Comment by verroq | Hacker News Reader

Those are?

I've wished I worked at places that saw this as a more serious problem. Ideally, we would know there's a cron that stopped working and we'd have to figure out which machine and which user it was on...then try and access it. Even the people that create them forget these things (myself included).

The most reasonable solution seems to use something like Jenkins--but I don't think anyone is happy with that.

At one job they wrapped crontab and used RCS to write to a network location. Now you can grep a single folder, its now version controlled, and you can wire any re-image script to restore crontabs. I've pitched this approach at subsequent jobs, but was never in a seniority role to get it rolled out.

If you're a JVM-oriented place I've had good experiences with Rundeck. Though it's a more polished equivalent of Jenkins rather than a step change.

Why do you think that not "anyone is happy with that." Jenkins for one works very well.

At most places I've been if there is something like Jenkins at all a single person sets up and troubleshoots the jobs. The average dev just looks at red/green, logs, and emails but only interacts with the code--maybe they manually run a job. So you're asking them to now author and modify things in Jenkins and I'm not even sure accounts and permissions were set up. So that's why the dev group isn't enthusiastic. Then you have sysadmins who otherwise have zero interest in Jenkins and aren't familiar with it at all.

Jenkins is a very capable app, but it's not "light" or approachable. Introducing it to new groups of people for an off-label purpose is a tough sell. If you're already heavily using Jenkins and that same group of people need it for periodic task scheduling it's an obvious choice.

setInterval(function, milliseconds)

That's just evil.

As long as that interval is less than ~24 days, IIRC.

Easy, use a global counter and only run the function when i % x == 0; i++;

If in the cloud: Something like AWS CloudWatch

If node.js: setInterval for short intervals, Bree for more complicated tasks [1]

If C: time_t

If Java: java.util.Timer, probably something 3rd party that better is wrapped around this

Anyways, the bigger point is that you should be expressing these interval settings in code, not system configurations. Everyone checks in source code but nobody checks in the crontab. It's better if you rely on the application to do these things rather than the system, because the system could always change beneath your feet (i.e. management says we're using Google Cloud now! Good luck porting a 200 line crontab to GCP) but you are in total control of your application's source code.

[1] https://jobscheduler.net/#/

I do keep the crontab under revision control.

We don't need these hipster webshit crap.

Probably systemd these days.

Honestly all joking aside systemd timer units have a lot of nice aspects. The only drag is that crontab entries are so much more terse and quick to add. Just one line instead of two unit files plus enabling/starting the timer. You can actually get the best of both with systemd-crontab-generator (not from the systemd project, just an unaffiliated third party).

https://manpages.debian.org/buster/systemd-cron/systemd-cron...

It creates transient unit files based off of a standard crontab on boot and after any file modifications. If you want to extend one of your cron jobs with something that you can't express in a crontab you can just mv it from /run to /etc and modify it however you'd like.

By chance, do you happen to know of any program that will add (and enable / start / etc) a systemd entry based on a valid crontab line?

Extra bonus points if it yoinks things the other way and lets you edit them as a nice crontab file that makes sense before re-integrating it in to the nightmare syntax.

Reply on news.ycombinator.com