GNU Mcron
gnu.org
gnu.org
Might be just me, but it's kind of like having another universe to take a vacation in.
It does make me miss types, doing data structure programming in scheme can be irritating I guess, but still. I can compose, I can syntax-rules if I wanted, etc.
The sexpr universe isn't dead yet.
The type situation irks me because I do ocaml for a living, so I rely on the type system a lot. Scheme reminds me of a more seductive flavor of FP, though sometimes it's cumbersome to ensure that a data structure isn't being subtly changed somewhere.
Scheme actually tried to compete with CL once, with a language called T. It had something sorta similar to CLOS and if I recall it was aiming for optimized performance per Sussman and Steele, but it eventually languished.
SBCL is the only thing keeping CL alive and they don't have the wherewithall to begin a modernized spec.
I don't hate CL, but I LOVE scheme. It is much more pleasant to actually work in, and feels cleaner. All the potholes of CL leave me checking under my fingernails for grime.
Scheme was implemented as a clean toy/educational Lisp on top of Maclisp in the mid 70s.
Scheme was defined too small upto R5RS and in R6RS is got unlispy.
> Scheme actually tried to compete with CL once
It never really did, since all implementations were different. There are lots of great Scheme implementations (MIT Scheme, Chez Scheme, ...) - but all were different. Then a bunch of extension were bolted onto Scheme - but the base was too small.
> It is much more pleasant to actually work in, and feels cleaner.
Which Scheme? Chicken Scheme? Racket - which is no longer a Scheme? Kawa? They are cleaner than CL?
The last clean Scheme was R5RS - and that was underspecified as a programming language.
Whenever I used Scheme I missed keyword arguments, CLOS, LOOP, optimization declarations, type declarations... Oh, wait. All those and much more has been added to Scheme in some ways. Unfortunately the result does not look 'cleaner'.
Chicken Scheme:
(define-method (pop (stack <stack>))
(let* ((c (slot-value stack 'content))
(x (car c)))
(set! (slot-value stack 'content) (cdr c))
x))
(defmethod stack-pop ((s stack))
(pop (slot-value s 'content)))That's all true enough; I believe that non-hygienic macros are a vital capability of a programming language (and Common Lisp being a Lisp-n makes them much less of a problem), and that LOOP is okay. I don't mind the cruft much: it's a mostly-backwards-compatible language, and backwards-compatibility is important; it's why Lisp code from the 80s can still run now, almost 40 years later.
I don't hate Scheme, really: it's a very neat little language. But it's completely unsuited for production work on large systems, which are what I'm interested in. Case in point: call/cc. It's nifty, really cool and absolutely has no place in any production system — it's ultimately just a very-lightly-structured GOTO.
And anyways, isn't that the case with most software? HN loves APL, but there's only a few implementations around any more, Arc used to be the big topic of HN, it's all but dead, software comes and goes.
Scheme will die someday, or change enough that its something different, but the lessons of programming with linked lists and eval will stick around in those that bother to learn them. Ie, people like you and I.
Maybe you should check the Savannah repo. Maybe they need some work done that you could do!
(job (lambda (current-time)
(let* ((next-month (next-month-from current-time))
(first-day (tm:wday (localtime next-month)))
(second-sunday (if (eqv? first-day 0)
8
(- 14 first-day))))
(+ next-month (* 24 60 60 second-sunday))))
"my-program")
0 0 8-14 * * [ `date +\%u` = 7 ] && my-program
I didn't know about mcron until this post either, but I find it super frustrating when people dismiss tools, ideas, or people simply because they don't conform to familiar patterns.
uschedule my-job "Sun *-*-8,9,10,11,12,13,14"
OnCalendar=Sun *-*-8..14> The new idea is to read the required command instructions, work out which command needs to be executed next, and then sleep until the inferred time has arrived. On waking the commands are run, and the time of the next command is computed.
> Each user looks after his own files in his own directory. He can use more than one to break up complicated cron specifications. Each user can run his own daemon. This removes the need for suid programs to manipulate the crontabs, and eliminates many security concerns that surround all existing cron programs.
> Vixie cron is implemented in 4500 lines of C code; mcron is 1500 lines of scheme, despite the fact that it offers many more features and much more flexibility, and complete compatibility with Vixie cron.
[1] https://www.freedesktop.org/software/systemd/man/systemd.tim...
take oddjobd for example, which supplants pam_mkhomedir.so in creating a users home directory on first login. oddjob is its own standalone daemon running constantly, while pam_mkhomedir is invoked only as necessary. oddjob needs dbus and systemd to complete what in many systems is just a simple mkhomedir && chown user:grp $homedir. its now fully dependent on the most fundamental building blocks of your OS to do one simple thing.
this also assumes the user doesnt have a home directory...which...many do.
in most commercial infrastructure if you suggest installing oddjobd to handle the potential for a user to log in without their home youll be laughed out of the chat. oddjobd forces organizations back into the 1980s and NIS based implementations of federated authentication where you had to go to a new user machine, or an account creation machine first if you dont want to run yet another idle daemon on your machine
I don't see any of that citation. Or evidence.
Just because you deem something overly complicated doesn't mean that it doesn't serve a practical purpose.
You don't want to go to all the effort to spin up a CPU core to schedule a (cron) process thread, just to find out it has no work to do. Ideally, if you're going to check the time at all, you just want it done in one thread running on one core, so that the rest of the cores can stay asleep and you never have to spend energy context-switching when idle.
That being said, systemd isn't quite the right architecture for getting down to a "tickless everything" system. That'd be something more like WinNT's kernel timer object API, where the kernel sends an event to your window's or service's message inbox to wake you up when the timer is done; or macOS's "Grand Central Dispatch", where any native code (including non-Foundation POSIX code!) can pass scheduling control of any async block through a Mach trap over to one central scheduling process, which coalesces both timers and the runtimes of async events in general so that all background CPU activity happens in bursts with idles in between.
Right now, I am doing this all with a mess of shell scripts (flock + logger + echo calls + pgrep). This is fragile and ugly.
Since systemd provides all of the above easily, a better approach will be one-off systemd jobs. In this case, my crontab entries would be a trivial -- "1 3 * * * root systemctl start cronjob1". This only requires scheduling functionality -- background execution, env vars, email notification and other things no longer matter.
From there, it is just one small step to move scheduling into the init process itself -- after all, compared to what other things init does, scheduling is both simple and safe.
Different tools suit different people. Cron isn't dying any time soon just because the casual Linux user is better served by systemd.
simpler to the point that you need whole libraries and helpers (such as https://www.freeformatter.com/cron-expression-generator-quar...) to convert from readable time to cron specifications ?
Meanwhile, sd is just
[Timer]
OnCalendar=weeklyBut you loose the main point, that is consistency of syntax. Nowadays thanks to systemd I can use the exact same syntax to configure my daemons, my network, my DNS resolver, my timers, my locale, etc etc. The mental burden is way lighter than with the traditional UNIX toolset.
You could have made the same consistency and mental burden argument about the crontab syntax. There are a lot of things in Unix which are table-driven and the tables take the form of one line per record with fields delimited by whitespace, blank lines ignored, and line comments introduced by hash.
Indeed these are your job scheduler (crontab), your mount points (fstab), your local host name resolution (hosts), your NS switch (nsswitch.conf), your terminal login services (ttys), your device permissions (fbtab), your automounts (auto_master), your plug-and-play device permissions (devfs.conf), your network services (inetd.conf), your MAC policy (mac.conf), your local network name resolution (networks), your call-out telephone numbers (phones), your network protocol name map (protocols), your RPC service map (rpc), and your network port name map (services).
And those are just the ones in /etc .
This set of table files with a common syntax is just as consistent and as light a burden as the set of .INI files that you are talking about. And any argument that you can make about things like having to remember what the fields mean can also be made just as much about the .INI files.
You only "need" to read the man page - the same as with systemd (asuming it still uses man, and not its own custom help viewer). If you'd read said man page, you'd know you can just type @weekly, for such a simple time period.
It never became it, either. It was fairly quickly forked. Several times. Debian cron was forked from PD cron in 1994 by Ian Jackson, for example. The "standard one that everyone used to use" but only in the limited field of Debian Linux (and no longer, nowadays with Debian Linux version 9) was that fork, which M. Jackson actually named "Debian/GNU Linux's". RedHat made a comparatively much more recent fork. OpenBSD and FreeBSD have their own (different from each other) forks of long standing, too.
Mike Meyer apparently made a GNU cron for the Free Software Foundation in 1987. If it indeed ever existed in the first place, it has since disappeared without a trace.
I provide pre-made service bundles for the nosh toolset for various crons, and I have so far had to make separate ones for Dillon crond, Debian cron, Vixie (a.k.a. ISC or PD) cron, Guenter bcron-{spool,start,update}, Godouet fcron, and OpenBSD cron; because they are significantly different from one another.
In part, this is because although the crontab utility is actually standardized, in the SUS, cron (like many such non-ordinary-user-facing internals) is not standardized. This is actually a good thing, inasmuch as the radically different multiple untrusting dæmons architecture of Guenter bcron would not have been possible if it had had to conform to a standard of one monolithic cron dæmon.
What's that mean though? It's entirely meaningless unless you, what's that, check the manual. Or what if you want it to run on another day? What's that? Check the manual? Sound familiar?
In particular: which day of the week, and at what time?
cron expressions have about as much learning curve as ISO-8601, and are otherwise unambiguous once you know how to read them. systemd's time specifications look like they're full of special cases:
https://www.freedesktop.org/software/systemd/man/systemd.tim...
Why is that simple? Monday isn't even the first day of the week!
But ISO 8601 is the standard so it makes sense to use that.
They also have other desirable behavior like being able to configure it concurrent runs are allowed or if the script should run if the initial date was missed or even restart the job if it fails up to a limit.
It's much more versatile than simply cron, due to that, it's also a lot more useful.
https://www.freebsd.org/cgi/man.cgi?crontab(5) is 1400 or so.
I'd hardly call that impenetrable. Additionally you will note that free bad has an extension to the format for shortcuts like monthly, weekly, &c.
I should note that `man crontab | wc` returns 1680 words while `man systemd.timer | wc` returns 1300 words. Take that for what you while, especially since .timer spends most words on explaining the options instead of the syntax.
I just don't want cron doing randomized delay and repeats. That should functionally be determined by the application.
I think it's perfectly fine that timer does this, it's useful. The applications I run don't support this behaviour out of the box, so why should I have to code up something for each app?
>There's little functional difference between syntax and options in this case,
There is an important difference. The manpage on timers spends most words explaining what exactly each option does and how it can be useful while most of the crontab manpage explains how the syntax works, the options crontab provides are minimal.
?
Cron, busybox and friends are still good things to master.
don't you ? my phone from 2013 runs systemd and wayland.
It's also an extremely niché phone... Witch I seriously wanted to try out, but couldn't because it was actually impossible for me to buy.
It's definitively not representative for phones in general, and certainly not for embedded Linux as a wider term.
Edit: Things might be changing though.
For instance my Netgear NAS used to run a custom Debian-derivative based on Debian 7 (which used sysvinit). But I discoverd today that after some recent updates it's now based on Debian 8 (which ships with systemd instead).
Based on that, I could produce the following plot[1], on a "embedded" device. Which I now know spends a tremendous 42 seconds booting the kernel. I guess it contemplates life, the universe and everything before moving along :)
[1] https://gist.github.com/josteink/3cf87479b97d8ab3eac81cba719...
It has made my life miserable more than once, but looking at how many hours I've spent working around it, I can see why consulting companies love it.
But seriously though, it solves a lot of problems around dependency and device management, error handling, logging, timer management, and so forth. To be sure, it has a steep learning curve, but I've found the effort invested to be well worth it.
As for the timer functionality in systemd, the configuration language is, IMO, far easier to understand. It doesn't get any easier than:
[Timer]
OnCalendar=weekly
[Timer]
OnStartupSec=0
OnActiveSec=1hYou mean, besides all the highly-available systems on which it currently runs? Since it's already part of the two most-used distributions in the world, it's fair to say that it's gotten sufficient exercise such that all of the serious kinks have been worked out by now.
Also, I'm not sure what you mean by having to "update all the time." Sure, systemd gets occasional security/bugfix patches, but so did sysvinit. And like sysvinit, systemd is hot-reloadable, so it's never been a problem in practice.
> I can't imagine using a legacy solution anymore.
Good thing sane people are improving on the legacy space then, with mcron--the subject of the link before someone had to mention SystemD--being a case in point.
It's also not just a matter of time before everyone switches over, since there's been backlash against systemd and competing projects have either started up, or gained more momentum (except for upstart, obviously!).
One of those alternatives is the "dmd" init system, which seems to have been around for a while but has recently been rebranded as "GNU Shepherd". Shepherd follows the "do one thing well" philosophy, so it only manages daemons. If shepherd users (e.g. GuixSD) want to run scheduled commands, they'll need another program to do that (i.e. a cron daemon), and GNU Mcron looks like a sensible choice since all of these things are configured using Guile Scheme.
As a side rant: I dislike your use of the term "legacy" for something which is actively maintained and gaining users. Usually "legacy" refers to something which is either abandoned, or where the maintainers recommend against adopting it (e.g. "that's our legacy API, use this other one instead"). I think the word "traditional" would work, when talking about cron in general; although Mcron in particular doen't look like a particularly traditional cron (since its selling point is using Scheme for config!)
It looks like Greenspun's Tenth Rule has been taken to the next level. Software that's so configurable its configuration files itself are written in a Turing-complete language is the bane of enterprise development. IMHO if you need such complex requirements, that should be done by something other than the configuration file of what should be a simple task scheduler.
It gives you standard vixie Cron AND the possibility to handle everything as a scheme program. You just put a scheme file in your Cron dir and have the logic in there. Really not much different from executing a shell file from regular Cron.
Moreover, "a simple task scheduler" is a simple task scheduler. It's written in 1500 lines of scheme code, another commenter quotes.
Is that a silly example? Yes. Is it realistic? Perhaps. As the company I work for transitions to an "Enterprise Class" company, I'm seeing a lot of silliness in processes.
Latest version 1.1.1 released 2018-04-08 [1][2]. Previous version was 1.1 on 2018-03-19, and the one before that dates to 2010-06-13 [2].
This is a job scheduler compatible with vixie-cron [3], but written in Guile Scheme. Entries in a crontab file can be the traditional format, or snippets of Guile. There's a whitepaper from 2003 [4] and up-to-date documentation [5] that explain the rationale and usage.
[1] http://lists.gnu.org/archive/html/info-gnu/2018-04/msg00004.... [2] http://savannah.gnu.org/projects/mcron/ [3] https://directory.fsf.org/wiki/Vixie-cron [4] https://www.gnu.org/software/mcron/design.html [5] https://www.gnu.org/software/mcron/manual/mcron.html
> The mcron program represents a complete re-think of the cron concept originally found in the Berkeley and AT&T unices
"Unices" as in the plural of "Unix"? I've never heard that before, but that's amazing.
I was using "Pentia" as the plural for "Pentium" soon after the original chip dropped.
flock -xn /path/to/lock -c /path/to/commandIt wouldn't have been too difficult to take the small introduction from here: https://www.gnu.org/software/mcron/manual/html_node/Introduc...
"Gnu Mcon- a 100% compatible replacement for Vixie cron"
Would be a -way- better title.
HN seems to love to announce random products and updates without telling anyone who doesn't already know what it is.
"Gnu Squanchydoo v3 released!"
TF is "Squanchydoo"? No idea, not going to bother to find out...
How does mcron's working differ from cron's ? That's what should be on the front page, not the language its written in.
It certainly isn't likely to make me question the choice I made to use the cron that my distro came with.
Or at a minimum they could have had one little section titled, "What is Mcron?", followed by a link to that introduction page in the docs.