More Dynamic Cronjobs

Running a command is the main idea of cron. In this case, the author runs composite commands like:

    test && action

Where 'test' is another shell command that returns 0 or 1. This is not a special cron syntax, it's just the inherent power of the Unix shell.

We tried doing it with Cron and gave up. If process cannot run during a holiday, it's now mandated that it's handled in code to launch, check holiday.json which is just array of dates and exit without doing work.

At our company we have enough systems reliant on holiday dates that we have a Holiday system that emits events when there are changes.

This happens surprisingly often, given that religious dates change and there are holidays/closures for storms in some regions.

I think this could be solved quite similar to the OP and better done with systemd. Spitballing, but I think the best thing to do would be to write the timer in a standard file but have the activation time be written in an override file. That way you can ensure you are just editing that file with your scraper (should be able to hit the API if it is something like a google calendar or outlook).

I think the systemd timer would give you the benefit here as you can write the time in varying formats. Timezones, UTC, local, or whatever. That should give you the structure you need, if I'm understanding your problem correctly.

While systemd has more boilerplate than cron I think it has a lot of advantages that make it worth it. Best to just have a skeleton of these jobs (I keep some in my dotfiles) and then you have it. Or have the LLM write it (ironically one of the few instances I'll advocate for letting the AI write the code). You can do everything in the article and so much more.

https://man.archlinux.org/man/systemd.time.7

I had something come up recently that I think sounds similar. It needs several time-sensitive jobs. When any one of them runs, the first thing it does is check a holidays.json file.

It parses the file using jq and compares its entries with the current time according to GNU date. At the root is the names of the jobs. Each job has its own list of holidays. Each of these holiday items in the job's respective list has keys for the display name of the holiday, the formatted date to compare to, and in a few cases the ISO day-of-week and a string containing a modulo arithmetic function (e.g. don't run the friday before Christmas, etc.). Sorry, yes that means I call eval and yes that means some of these are repeated in the same file under the arrays for the other jobs.

I don't know if that helps. I know it's hacky, but I don't think there's a nice way to handle things like "second monday after 4th of july, but if the 4th also happens to be monday then it should instead be the second tuesday".

Ruby has https://github.com/bokmann/business_time but we needed to write custom code for handling holiday weekends

Not sure what do you mean. I.e., what exactly is supposed to be the tricky part. Yes, I've dealt with quite a few processes like that, but I never tried, or would ever want to to put this into crontab. In fact, I don't know how the author intended his article, but if you consider doing that for production, I strongly advice you not.

What you do instead, is you schedule the cronjob for the most generic case, e.g. each day. And if it does not need to run 3 days before holidays with crescent moon when wind is blowing from the south, it is just the part of business logic of the process, which you write in the any proper programming language that you prefer (or that the system is written in anyway).

Now, how do you manage the list itself depends on the details and I've done all sorts dirty things that one probably shouldn't do (cutting corners), but in the most flexible case it is just some CRUD-type page in your back-office system, with a real UI, and there is a person (usually in the bookkeeping department of the company) who has it among his responsibilities to maintain the schedule. You store it in some proper SQL database and cache it aggressively, so the the myriads of cronjobs don't bother it more than necessary.

This sounds like a really fun idea.

> making the timing of the next run independent of the last via the memoryless property of the exponential distribution

Nit: you’re not relying on the memoryless property here but just plain old independent sampling. You’re right that memorylessness means that the elapsed time since the last job provides no information on when the job fires next, but this is orthogonal to the independence of the sleep intervals.

Have you tested how this behaves on eventually consistent cloud storage?

We can also use systemd timer and it ensures there is no overlap.

https://avilpage.com/2024/08/guide-systemd-timer-cronjob.htm...

Good advice. You can also check in and version your crontabs (or timer units or whatnot) directly.