Or... y'know... likes a good story. (Involving cron!!)
Well, this is the thread for you...
Recently, one of my cron jobs entries wasn't running the way I'd intended, so I pulled out the trusty crontab(5) manpage.
After skimming it and trying (rather unsuccessfully) to fix the issue, I decided to grab a cup of coffee and actually sit down to READ the thing.
Now, as many of you cron fans probably know, you specify the time to run the job using a format—an esoteric one, which we've all flubbed at some point—generally using digits.
But, for certain fields, you can also use symbolic names instead of numbers ("Wed", "Feb").
You can ALSO, as lots of you know, specify ranges and lists in your cron job specification, too. To run the job on weekdays, for example, put "1-5."
But, as I was ACTUALLY READING the manpage, I came across a phrase that puzzled me: "Ranges or lists of names are not allowed."
Now, raise your hand if you have crontab entries somewhere with a "mon-fri" or a "jan,apr,jul,oct".
Yah... I do too.
(Upon reading this sentence in the manpage, I broke into a cold sweat as I realized potentially these cronjobs had NOT BEEN RUNNING... y'know... maybe EVAR.)
But I took a breath and remembered "Wait. No. I KNOW at least SOME of those jobs are running. I've seen email output from a few of 'em."
So I started trying to figure out what was going on...
First, to make sure I wasn't hallucinating: I created a set of test cron jobs that just output an email, using both lists and ranges of weekday *names* in the entry spec.
I waited in suspense EVERY MORNING to see if the cronjob ran, and... sure enough, I got my emails all week.
Then I decided to go dig into the source code.
There are a number of cron implementations. I use cronie, which is a common one, notably used on RedHat systems.
Now, if you click on through to that link, you'll see some serious C string parsing. I haven't had to think about C strs in years.
(Reading this code caused nightmare flashbacks to a Systems Programming assignment in college where we had to build a homemade shell...)
As I read through the call logic, I noticed a get_number() function used by some get_list() and get_range() functions. Curiously, get_number() is passed a string array that contains... weekday & month names!
And there's definitely some strcasecmp()'ing going on in get_number()!
(There's also a fun comment that's pretty revealing:
/* No numbers, look for a string if we have any */
So, based on my rusty, buffer overflow-riddled C string pointer parsing skills, lists and ranges of weekday and month names... SHOULD... work... ????
(And besides, I had the results of my little experiment, which worked, so... the docs HAD to be wrong... right?!)
Well, because it's a global pandemic and... y'know... I didn't have anything better to do, I decided to dig a bit further.
cronie was forked from vixie-cron 4.1 back in 2007, according to the ChangeLog in the source.
I check the v4.1 manpage: "Ranges or lists of names are not allowed."
And the crontab entry parsing source sports a familiar phrase:
/* no numbers, look for a string if we have any */
So vixie-cron v4.1 seems to support named weekday & month ranges & lists, same as cronie.
I decided to keep digging, because... #pandemic: I started by looking for the oldest version of vixie-cron I could find.
This turned out to be somewhat difficult, because vixie-cron isn't maintained anymore, so all my searches resulted in that same v4.1 source tarball.
But then I vaguely seemed to remember seeing Paul Vixie's name on #techtwitter somewhere... and sure enough: @paulvixie.
So... let's DM him. (Why not? Maybe he's as bored as I am.)
I ask if he still has an RCS or CVS (but NOT Git! OR Perforce.) repo of the vixie-cron sources.
HE ACTUALLY REPLIES TO MY DM!
He said he had some ,v files of the original source, but they're difficult to dig up for... #reasons. But he mentioned he posted the source code to comp.unix.sources back in the day.
(Small digression for those not in the know: comp.unix.sources was a Usenet *newsgroup* where people shared source code for various Unix. Back then, there was no Github or Gitlab or Sourceforge...
The source code would be all smooshed together in tangles of plaintext formatted tar-ish archives and uu and base64-encoded gunk, often in multiple messages. God help you if one message was missing in the thread. People even posted patches in the Usenet threads! Fun-times!)
(Fun [modern] fact: for all you folks who think Git is so chic and fancy: guess how the git developers distribute patches to the git source code? THEY POST PLAINTEXT, MULTIPART PATCHES TO A MAILING LIST, just like they did back in the comp.*.sources days: marc.info/?l=git&w=2&r=1…)
So back to cron: off I go comp.unix.sources spelunking.
The oldest version of vixie-cron I can find in posted archives is version 2.0, submitted by none other than Vixie himself, of course!
Time to look at the source, which I find posted as three files that... you were supposed to cat together, and then untar them? I guess?
(I still had to look up the damn order of the tar arguments to get them right though...)
ANYWAY, so first:
Are named weekday/month ranges supposedly not allowed in this old (v2!) version?
Manpage says no: "Use the first three letters of the particular day or month (case doesn't matter). Ranges or lists of names are not allowed."
Does the source code parse strings though?
It's certainly different code, but it's obviously a distant relative: our friends get_list(), get_range() & get_number() all appear. Sure enough, deep down in get_number(), there's a comment:
/* try to find the name in the name list */
Just to be sure, I dug to find the string arrays that are being passed around; sure enough, the code references:
It turns out vixie-cron supported the named lists and ranges cronjob spec feature! (BACK IN 2.0!!)
Back on Twitter, I ask Vixie if he remembers the history, or why there's a mismatch.
He quickly replies: "Oh, I didn't support ranges or lists of names at first. When I fixed the code, I didn't fix the man page.
So, simple pilot error."
(I'm sure if Vixie knew me better, he'd know I both cringed at "pilot error," WHILE ALSO SIMULTANEOUSLY loving this entire story.)
BUT, either way: YES! CONFIRMATION THAT MY RUSTY C SKILLZ WEREN'T TOTALLY WRONG!!!
Wanting to be a good open source citizen (and NOT wanting all this digging to be for nothing) I put together a pull request for cronie: github.com/cronie-crond/c…
It got accepted.
When the next version is released, the manpage details on named day-of-week and month ranges and lists in crontab entries will match the actual behavior of the program...
some 30 years and 9 days later.
(I'd like dedicate this thread to @wiredferret and ALL the folks who work on docs and other parts of software that aren't what we generally think of as... "the software," but which is work that keeps us from going into cold sweats because we observe different behavior...
... it's often thankless work, and the world would be a better place if we all did a lil' bit more of it.)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The study of human factors is inextricably rooted in examining how humans use (often complicated) tools to perform work.
One of the first papers any student of the field will read is Fitts and Jones' 1947 paper on the subject. THREAD.
You're probably familiar with this paper, even if you don't know it: it's a write-up of the investigation of planes that kept "collapsing" in various World War II theaters; it found that the aircraft gear and wing flap handles were next next to each other... and identical.
Once they reshaped the handles—flap control like a flat... well... flap & a circular knob for gear—incidents of that particular type of "human error" were reduced significantly.
(The paper is foundational because it also argues why further study of human factors is important...)
A friend recently asked me "Hey, this @REdeployConf thing you're doing sounds pretty interesting... but I'm not sure whether it's for me."
"Well..." I replied...
THREAD:
First some context: I had the original idea for bringing people together to talk about resilience in technological systems last year, during my first year in my Human Factors and Systems Safety masters.
I spent a lot of time thinking about what people like @jesserobbins and @adrianco (and others) have talked about for a long time about what building resilient technology looks like, and what it meant in the context of the safety science lens we were looking at it through.