5 ms·

It can be argued that Systemd does do just one thing, and well. Unix has a process model which has historically been lax. Things built on top of it tend to be

It can be argued that Systemd does do just one thing, and well. Unix has a process model which has historically been lax. Things built on top of it tend to be shell scripts. Cron is probably the worst example of "do one thing well", because it does that one thing very poorly. It can only start stuff. If you want to avoid dogpiling, enforce timeouts, enforce resources, prevent multiply-forking jobs from leaving orphan processes, preserve historical per-job output, pause or delay jobs, manually start jobs, balance jobs across multiple nodes, etc. — then you just have to cobble that together yourself. I certainly have. What "cron" and "/etc/init.d/something" and "scripts that run on ifdown/ifup" and "scripts ran run on DHCP changes" and "scripts that run at specific times" have in common is that they are arbitrary processes whose lifetimes are bounded — by time (cron-like behaviour), dynamic events (such as networks going up or down), human input (manual start or stop) or other factors. There's no conceptual difference between a clock and a human action, for example. If job X is set to run at midnight, and I want to run it a little sooner today, couldn't I just trigger it manually? For Cron to have this, and for Cron to fix the other deficiencies I mentioned, it would have to replicate features to the point where it becomes... Systemd. Because Cron starting processes at specific times is just a special case of starting processes at boot (init) or starting processes when networking goes up (/etc/network/if-up.d or whatever). Systemd is a process lifecycle supervisor. It tracks the lifetimes of processes. That's about it. Everything else is pragmatic problem solving. Just like grep's simplicity ("finds stuff by text") is clouded by the dozens of arcane flags it must support to real-world use cases (styles of regexps, reading patterns from a file, printing options), so must Systemd cater to many minor aspects. It can be argued that Systemd could be less monolithic and more pluggable, but I feel that's another story.

simoncion 11y ago
> It can be argued that Systemd does do just one thing... Systemd is a process lifecycle supervisor. It tracks the lifetimes of processes. That's about it. It's also a /dev node manager, and a syslogd replacement, and a cron replacement, and a dhcpcd replacement, and a mount/umount, insmod/modprobe reimplementation, [0] and a bootloader, [1] and... The systemd project is huge, sprawling, and continues to grow. > Cron is probably the worst example of "do one thing well", because it does that one thing very poorly. It can only start stuff. [If you want something sophisticated you inevitably have to implement systemd.] It turns out that you don't! Check out fcron. Its crontab is described here: [2]. If you're impatient, search for "The options can be set either for every line". > Things built on top of [Unix's process model] tend to be shell scripts. The phrase "shell scripts" gets tossed around like it's a slur. What are the essential differences between a Bash program, a Python program, a TCL program, an Erlang program, and a C program that all do the very same thing? What makes "shell scripts" so undesirable? [0] Given the number of times things like recursive bind umounts, module loading/unloading, and more core stuff have broken on systemd-enabled systems and only such systems, it's almost impossible to believe that mount/umount, insmod/modprobe & etc. aren't being reimplemented in the systemd project. ;) [1] https://wiki.archlinux.org/index.php/Systemd-boot https://wiki.archlinux.org/index.php/Systemd-boot [2] http://fcron.free.fr/doc/en/fcrontab.5.html http://fcron.free.fr/doc/en/fcrontab.5.html
- atombender 11y ago
  > Check out fcron ... Well. * Can it let me start jobs manually? * Can I defer their scheduling programmatically without editing a file to comment it out? * Can I add or remote new jobs programmatically and atomically? * Can I ask it about the status of a job? * If a job fails, is it retried, up to a limit? * Can I give it a time budget after which the job is killed? * Can I give it a resource budget (e.g. CPU usage)? * 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? * Can I programmatically start jobs, edit jobs, etc. from a different host? * 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? * If the job runs so long that it overlaps with the next scheduled period, can it ensure that the next job doesn't start yet? * If the job forks, can it ensure that the children are cleaned up? These are some of the features that I want from a job scheduler. Yes, some of it can be cobbled together with wrapper scripts, manual cgroups, and so on. But I don't want to write all of that. > What are the essential differences between a Bash program Shell scripts are brittle. That's hardly debatable. 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. A lot of people don't know about classic safeguards such as "-e", "-o pipefail", exit traps and so on. Some of the safeguards you want are hard to do safely and atomically. 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. You get errors and information output intermingled and there's often no way to tell who emitted it without going step by step. Throughout my 20+ years of using Unix variants, shell scripts and "shell-scripty interdependencies" have always been a source of problems, usually related to things like escaping, quoting, option parsing, alias expansion, variable expansion, bad toolchain detection (e.g. assuming your "ls" is GNU), ignoring exit codes, bad output parsing, etc. "find | xargs" works just fine until the day you encounter a file name containing spaces. Then you do "find -print0 | xargs -0" and you're happy until the next edge case comes along that touches on space handling, of which the shell language family is rife. It gets worse when shell scripts try to be nice over SSH. At least languages like Python and Erlang have 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'm not a huge fan of Go, but Go is a surprisingly good fit for command-line tools, and its strictness and static typing helps avoid a whole class of errors. I love shell scripts, and I write them nearly every day, but I would never build an OS on top of them.
digi_owl 11y ago
Cobble together, composeable, same diff, no?

simoncion 11y ago

> It can be argued that Systemd does do just one thing... Systemd is a process lifecycle supervisor. It tracks the lifetimes of processes. That's about it. It's also a /dev node manager, and a syslogd replacement, and a cron replacement, and a dhcpcd replacement, and a mount/umount, insmod/modprobe reimplementation, [0] and a bootloader, [1] and... The systemd project is huge, sprawling, and continues to grow. > Cron is probably the worst example of "do one thing well", because it does that one thing very poorly. It can only start stuff. [If you want something sophisticated you inevitably have to implement systemd.] It turns out that you don't! Check out fcron. Its crontab is described here: [2]. If you're impatient, search for "The options can be set either for every line". > Things built on top of [Unix's process model] tend to be shell scripts. The phrase "shell scripts" gets tossed around like it's a slur. What are the essential differences between a Bash program, a Python program, a TCL program, an Erlang program, and a C program that all do the very same thing? What makes "shell scripts" so undesirable? [0] Given the number of times things like recursive bind umounts, module loading/unloading, and more core stuff have broken on systemd-enabled systems and only such systems, it's almost impossible to believe that mount/umount, insmod/modprobe & etc. aren't being reimplemented in the systemd project. ;) [1] https://wiki.archlinux.org/index.php/Systemd-boot https://wiki.archlinux.org/index.php/Systemd-boot [2] http://fcron.free.fr/doc/en/fcrontab.5.html http://fcron.free.fr/doc/en/fcrontab.5.html

atombender 11y ago
> Check out fcron ... Well. * Can it let me start jobs manually? * Can I defer their scheduling programmatically without editing a file to comment it out? * Can I add or remote new jobs programmatically and atomically? * Can I ask it about the status of a job? * If a job fails, is it retried, up to a limit? * Can I give it a time budget after which the job is killed? * Can I give it a resource budget (e.g. CPU usage)? * 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? * Can I programmatically start jobs, edit jobs, etc. from a different host? * 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? * If the job runs so long that it overlaps with the next scheduled period, can it ensure that the next job doesn't start yet? * If the job forks, can it ensure that the children are cleaned up? These are some of the features that I want from a job scheduler. Yes, some of it can be cobbled together with wrapper scripts, manual cgroups, and so on. But I don't want to write all of that. > What are the essential differences between a Bash program Shell scripts are brittle. That's hardly debatable. 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. A lot of people don't know about classic safeguards such as "-e", "-o pipefail", exit traps and so on. Some of the safeguards you want are hard to do safely and atomically. 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. You get errors and information output intermingled and there's often no way to tell who emitted it without going step by step. Throughout my 20+ years of using Unix variants, shell scripts and "shell-scripty interdependencies" have always been a source of problems, usually related to things like escaping, quoting, option parsing, alias expansion, variable expansion, bad toolchain detection (e.g. assuming your "ls" is GNU), ignoring exit codes, bad output parsing, etc. "find | xargs" works just fine until the day you encounter a file name containing spaces. Then you do "find -print0 | xargs -0" and you're happy until the next edge case comes along that touches on space handling, of which the shell language family is rife. It gets worse when shell scripts try to be nice over SSH. At least languages like Python and Erlang have 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'm not a huge fan of Go, but Go is a surprisingly good fit for command-line tools, and its strictness and static typing helps avoid a whole class of errors. I love shell scripts, and I write them nearly every day, but I would never build an OS on top of them.

digi_owl 11y ago

Cobble together, composeable, same diff, no?