3 ms·

Several of the items in your bulleted list make it seem like you either didn't read all of, or didn't thoroughly understand fcron's crontab manpage. I urge you

Several of the items in your bulleted list make it seem like you either didn't read all of, or didn't thoroughly understand fcron's crontab manpage. I urge you to go back and re-read the documentation, or -at least- the Options section. I'll address the items that aren't covered by the documentation that I linked to. :) > * Can it let me start jobs manually? > * Can I ask it about the status of a job? Yep. [0] > * Can I defer their scheduling programmatically without editing a file to comment it out? I'm not sure what it means to "defer" scheduling. That sounds like changing the time a job starts. If I'm wrong about that, please do let me know. :) Anyway. Every job scheduling system stores its non-volatile info on disk. fcron's full-featured interface to its job scheduling system is found in [1]. I don't know if that meets your requirement. > * Can I programmatically start jobs, edit jobs, etc. from a different host? Yep. [0] [1] > * Can I add or [remove] new jobs programmatically and atomically? AFAICT, yes. [1] > * Can it log the output tagged with an identifier that identifies the job uniquely across time? > * Can it notify me by some programmatic mechanism (so that I can pipe it to a webhook, say) if a job fails? Yep. That's in the email that it sends. What your reporting infrastructure does with that email is up to you. > * Can I ensure that only a single instance of the job runs in a cluster, if multiple hosts have been configured with the same job? AFAIK, Systemd doesn't do this, so I don't know why you're asking for it. (Other than the fact that it would be rather nice to have.) :) But, no. AFAICT, fcron runs on a single host. I have heard about chronos, though. [2] So, I need to preface the rest of this commentary with the following: Bash is clunky, kinda unwieldy, and very, very far from my favorite language. There are several reasons why I select Python for scripts that get much more complex than "rather simple". Please keep this fact in mind while reading the rest of my commentary. :) > Shell scripts are brittle. ... You can write solid shell scripts, but people generally don't because it takes a lot of effort and arcane knowledge to do it successfully. But C programs written by people who can't be arsed are also brittle and -even worse- the language itself is filled with hidden and subtle pitfalls! > Unix has a nice pipe system, but shell scripts that need to drive a lot of things invariably mess it up because everything pipes to the same place [and this makes unwinding intermingled output difficult sometimes]. So, why not religiously do something like using logger(1) with appropriate tags and ids? I mean, you actually have to work a little to get reasonable logging in (almost?) every language. Hell, -IIRC- C doesn't ship with anything substantially more sophisticated than printf(3) and friends. ;) > Then you do "find -print0 | xargs -0" and you're happy until the next edge case comes along that touches on space handling... How does IFS=$'\n' and/or the "${VAR}" pattern not fix all space handling problems when using bash? (Bash is one of my weaker languages, so if you know, I'm genuinely interested in hearing about it.) However, if your answer is something like "Some other script you use might screw things up!", then my reply is "Bash and sh programs are not the only languages in which we might find an erroneous program on which we depend.". :) > It gets worse when shell scripts try to be nice over SSH. How's that? I'm seriously asking, for my own edification. > I love shell scripts, and I write them nearly every day, but I would never build an OS on top of them. I don't think that I (or anyone else who has an informed opinion on the topic of sysvrc replacements) has ever seriously suggested that one built an entire OS on top of shell scripts. Frankly, they're insufficiently powerful (not to mention [comparatively speaking] too damn slow) to reasonably accomplish the task. However, OpenRC -and so many other RC and init systems- demonstrate that shell scripts can provide rather powerful, relatively foolproof methods for a packager or service author to control services on their system. > At least ... Erlang [has] first-class support for primitives, even if their dynamic typing leads to a lot of potential situations where the runtime parameters aren't what the author assumed, and things blow up because someone didn't sufficiently duck-type. I am totally, seriously, not (!!) getting on your case here, but how much work have you done with Erlang? I'm a novice-to-middling Erlang programmer, and the situation you described seems... difficult to run into unless you're unusually careless. (Python, OTOH...) > I'm not a huge fan of Go... Me either! It's so opinionated. Does it still consider unused imports to be compile-stopping errors? :( [0] http://fcron.free.fr/doc/en/fcrondyn.1.html http://fcron.free.fr/doc/en/fcrondyn.1.html [1] http://fcron.free.fr/doc/en/fcrontab.1.html http://fcron.free.fr/doc/en/fcrontab.1.html [2] https://aphyr.com/posts/326-call-me-maybe-chronos https://aphyr.com/posts/326-call-me-maybe-chronos

lobster_johnson 11y ago
I could talk about this all day, but I don't have the time, so I'll just address some of your more important points. Fcron has some features that I like that I didn't find when I looked at it (the documentation is very poor: "dialog dyn-amically with a running fcron daemon" didn't really invite me to think that it had a job scheduling UI), but it's not sufficiently built out that I will be able to trade my current toolset for it. For example, it seems that it lacks any process isolation. Email-only reporting is not acceptable. And so on. I agree that Fcron is a better Cron. But I also think that it's a very poor Systemd. Like Systemd, it controls the lifetime of processes; it has an overlapping feature set (job files, backing store, control UI) and if one made it complete, it would look a lot like Systemd. I'd rather have one tool do process orchestration, rather than two. > But C programs written by people who can't be arsed are also brittle Certainly. But it's hard to write C programs that fail for the same half-assed reasons that shell scripts do. C programs suffer from other problems. I'd much rather have a C program segfault on bad input right away than have a shell script happily continue to run because it ran some text file through tr, got a different result than it expected, stored it in a variable, passed it badly-quoted to some tool 27 lines down in the script, and triggered an impossibly obscure error message unrelated to the original cause. But the real alternative isn't C, of course. It's one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical sloppiness of Unix. > How does ... not fix all space handling problems when using bash? There's much more to it than that, I believe. For example, preserving quoted arguments is a nightmare. Let's say you read some file that contains command-line options. It contains something like: -x -y --string="hello world" You want to read that, preserving quoting, into an environment variable, which you then want to modify and pass on to another script. Turns out this is hard. Normally, quoting "$foo" works; but the moment you fiddle with it, the quoting is lost. There's a neat bash trick few people know about which exploits its array support: #!/bin/bash configopts=`cat configfile` eval ARGS=($configopts) ARGS+=("--anotherflag") ARGS+=("$@") ./somecommand "${ARGS[@]}" Throughout this script, $ARGS' internal token structure is preserved, even when it's manipulated. There are other ways to accomplish this, but none of them are pleasant, and this way is quite pleasant, once you get past the weirdness. But I would bet that most developers don't even know that bash has first-class array support. (If you know a better solution, This is just one horrible corner case where a naive implementation would blow up. As I said originally, it's possible to write safe, resilient, mostly well-behaved shell scripts. But it's hard; you have to know about every possible pitfall [1] and divergent behaviour on GNU and BSD. Shell scripts implement most of their functionality through external commands, not functions, so you cannot assume much about the interface of commands. This takes time and effort. But shell scripts are easy to write, which invites sloppiness. Few people write unit tests for shell scripts. Few people use something like autoconf to sniff the runtime environment (e.g., GNU vs BSD). As for "entire OS built on shell scripts", every Unix distro out there is built on tons of shell scripts. Even Upstart and Systemd can hardly avoid using a bit of scripting. As for SSH, you're in a pretty good spot if you send your script using <<'EOF and disable the tty. Otherwise you run into quoting issues fast, and scripts that expect interactivity will hang. There might be some other corner cases, I forget. Controlling SSH from scripts has always been painful and brittle for me. > [Erlang] ... difficult to run into unless you're unusually careless Sure. But it's there. Erlang's duck typing means it's susceptible to sloppy inputs just like any other duck-typed language. It's a lot better than the shell script situation, to be sure. [1] http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls

lobster_johnson 11y ago

I could talk about this all day, but I don't have the time, so I'll just address some of your more important points. Fcron has some features that I like that I didn't find when I looked at it (the documentation is very poor: "dialog dyn-amically with a running fcron daemon" didn't really invite me to think that it had a job scheduling UI), but it's not sufficiently built out that I will be able to trade my current toolset for it. For example, it seems that it lacks any process isolation. Email-only reporting is not acceptable. And so on. I agree that Fcron is a better Cron. But I also think that it's a very poor Systemd. Like Systemd, it controls the lifetime of processes; it has an overlapping feature set (job files, backing store, control UI) and if one made it complete, it would look a lot like Systemd. I'd rather have one tool do process orchestration, rather than two. > But C programs written by people who can't be arsed are also brittle Certainly. But it's hard to write C programs that fail for the same half-assed reasons that shell scripts do. C programs suffer from other problems. I'd much rather have a C program segfault on bad input right away than have a shell script happily continue to run because it ran some text file through tr, got a different result than it expected, stored it in a variable, passed it badly-quoted to some tool 27 lines down in the script, and triggered an impossibly obscure error message unrelated to the original cause. But the real alternative isn't C, of course. It's one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical sloppiness of Unix. > How does ... not fix all space handling problems when using bash? There's much more to it than that, I believe. For example, preserving quoted arguments is a nightmare. Let's say you read some file that contains command-line options. It contains something like: -x -y --string="hello world" You want to read that, preserving quoting, into an environment variable, which you then want to modify and pass on to another script. Turns out this is hard. Normally, quoting "$foo" works; but the moment you fiddle with it, the quoting is lost. There's a neat bash trick few people know about which exploits its array support: #!/bin/bash configopts=`cat configfile` eval ARGS=($configopts) ARGS+=("--anotherflag") ARGS+=("$@") ./somecommand "${ARGS[@]}" Throughout this script, $ARGS' internal token structure is preserved, even when it's manipulated. There are other ways to accomplish this, but none of them are pleasant, and this way is quite pleasant, once you get past the weirdness. But I would bet that most developers don't even know that bash has first-class array support. (If you know a better solution, This is just one horrible corner case where a naive implementation would blow up. As I said originally, it's possible to write safe, resilient, mostly well-behaved shell scripts. But it's hard; you have to know about every possible pitfall [1] and divergent behaviour on GNU and BSD. Shell scripts implement most of their functionality through external commands, not functions, so you cannot assume much about the interface of commands. This takes time and effort. But shell scripts are easy to write, which invites sloppiness. Few people write unit tests for shell scripts. Few people use something like autoconf to sniff the runtime environment (e.g., GNU vs BSD). As for "entire OS built on shell scripts", every Unix distro out there is built on tons of shell scripts. Even Upstart and Systemd can hardly avoid using a bit of scripting. As for SSH, you're in a pretty good spot if you send your script using <<'EOF and disable the tty. Otherwise you run into quoting issues fast, and scripts that expect interactivity will hang. There might be some other corner cases, I forget. Controlling SSH from scripts has always been painful and brittle for me. > [Erlang] ... difficult to run into unless you're unusually careless Sure. But it's there. Erlang's duck typing means it's susceptible to sloppy inputs just like any other duck-typed language. It's a lot better than the shell script situation, to be sure. [1] http://mywiki.wooledge.org/BashPitfalls http://mywiki.wooledge.org/BashPitfalls