3 ms·
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 w
by pfranz 6y ago
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.
- lmm 6y agoIf 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.
- foobarian 6y agoWhy do you think that not "anyone is happy with that." Jenkins for one works very well.
- pfranz 6y agoAt 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.