Cron as a filesystem | Hacker News Reader

Cron as a filesystem

blog.gopheracademy.com

64 pointsSwellJoe17 comments

Ahem, meaning "manipulate crontab entries in a vfs" and not "store files in cron".

Yeah, I considered changing the title to "File interface to cron" or something similar, but that also seemed to leave some of the reality out. It's just another element of the "everything is a file" philosophy of Plan 9, which I find very interesting and pragmatic, and wish were more common in the directions Linux is evolving in, with stuff like systemd, firewalld, systemd timers, etc.

How about "exposing cron as a filesystem"?

Sounds like a Fox News title, where they expose cron to secretly be a filesystem. They'll call it "crongate".

"What you need to know about Cron. News at 0 22 * * 1-5."

I find this an interesting experiment, as I am often struck by how much history seems to get forgotten. Plan 9 is pretty ripe for picking out lots of cool little things for integration into modern systems, but a lot of it doesn't seem to have resonated out into the world at large. It's unfortunate that Plan 9 wasn't Open Source from the beginning, as it might have been common enough to have inspired more stealing of ideas for other systems.

As it is, we've got a lot of reinvention of ideas happening, often without much forward movement.

That reflects a mindset from an OS where the only data structure is a file system. When the only hammer you have is a file system, everything looks like a tree. Chrontab is a database and should be treated as such.

The "everything is a file and files have no locking" mentality of UNIX doesn't scale well to continuously running systems.

"Chrontab is a database and should be treated as such."

Why a database?

"The "everything is a file and files have no locking" mentality of UNIX doesn't scale well to continuously running systems."

I don't understand what argument you're making here. UNIX doesn't actually have "everything is a file" semantics (cron does not, for example, in the sense proposed by the article). Plan 9 mostly does, and it's actually kind of awesome. What part of Plan 9's semantics of everything is a network-transparent file "doesn't scale"? And, what do you mean by "doesn't scale"?

I'm not trying to be argumentative, I genuinely don't understand what you're suggesting instead. What is an alternative cron implementation that is implemented as a database that "scales" better than something like this, by your definition? And, what is "scale" in this context?

Everything is a file doesn't scale to more than one system without resorting to hacks (Using NFS or the likes).

One condition for a scalable system is a network interface imho.

Cron doesn't have that as well, which usually leads to application level complexity to avoid running the same cron on multiple machines.

What!? Did you even read the article? It covers the fact that files are network transparent...i.e. every file is available everywhere on the network. You really should give the article a read and maybe read up on Plan 9 a bit. You're missing out on some really interesting stuff.

You've never heard of 9P, have you?

The problem with filesystems is that they don't usually support transactions. For example, it is not possible to atomically change two files, without resorting to ugly and dangerous hacks.

Right. If you're changing the configuration of a live system, you often want to do it atomically. Databases are designed for that. They also support search operations and have indexes, which get updated as the data changes.

Plan 9 came close. You could create /foo/a and /foo/b at your leisure, then bind /foo over /etc. This atomically replaced /etc/a and /etc/b with /foo/a and /foo/b, for the purposes of open. The change could be atomically reverted with unmount.

If that wasn't good enough, then /etc/a and /etc/b could be virtual files served by the same daemon. This could look for change sets written to /dev/patch, and block reads and writes while it applied them.

A file system is a database too, though.

A file system is not a data structure, it is an interface.

Reminds me somewhat of Debian's /etc/cron.{daily,monthly,weekly,monthly}

Reply on news.ycombinator.com