5 ms·

I think there's an argument to be made that these things dont belong in cron, they belong in logic that lives elsewhere. Do one thing and do it well.

simoncion 11y ago
> Do one thing and do it well. The trick is determining what thing you're going to do. I think it's perfectly reasonable for a job scheduler to have the ability to terminate jobs that run for too long and to ensure that no more than N copies of a given job are running simultaneously. This sort of thing also satisfies the DRY principle. :)
feld 11y ago
> Do one thing and do it well. People really like to parrot this statement. Nobody is going to make it do "more" than a scheduling tool. It's not going to become a volume manager or start steering your clock... Why aren't you angry about these redundancies: * sort's -u flag when there's uniq ? * grep's ability to search recursively when there's find ? * grep's existence when there's ed ? * cron's existence when there's at ? * cat's existence when there's < ? We could play this game all day.
- dijit 11y ago
  many of those things dont actually do the same thing. at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. ed/sed are powerful languages that are used for 'changing' data, not searching it.. it _can_ be used to search but it's very heavy for the task. grep also searches content of files recursively, where as find does not, having find do it means forking the process and being very heavy also. cat and < are different in that one is a shell builtin and is used to.. concatonate files.. which the shell builtins do not do... ofc many people "use it wrong" but that's neither here nor there in this discussion. https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat
  - simoncion 11y ago
    /me puts on Devil's Advocate hat > at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. Make recurring scheduled jobs reschedule themselves as their last action. This makes your job scheduler do one thing and do it well. :P > [ed] _can_ be used to search but it's very heavy for the task. So? ed was around before grep. Grep is therefore redundant. > grep also searches content of files recursively, where as find does not. The point there was that find can recursively create a list of files for grep to search, passing them along to grep. This means that grep's -r switch is redundant. /me removes Devil's Advocate hat > cat and < are different... If I had more time today, I would figure out if one can abuse the hell out of shell redirection to replace cat. It sounds like a fun way to waste a half-hour.
atombender 11y ago
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

simoncion 11y ago

> Do one thing and do it well. The trick is determining what thing you're going to do. I think it's perfectly reasonable for a job scheduler to have the ability to terminate jobs that run for too long and to ensure that no more than N copies of a given job are running simultaneously. This sort of thing also satisfies the DRY principle. :)

feld 11y ago

> Do one thing and do it well. People really like to parrot this statement. Nobody is going to make it do "more" than a scheduling tool. It's not going to become a volume manager or start steering your clock... Why aren't you angry about these redundancies: * sort's -u flag when there's uniq ? * grep's ability to search recursively when there's find ? * grep's existence when there's ed ? * cron's existence when there's at ? * cat's existence when there's < ? We could play this game all day.

dijit 11y ago
many of those things dont actually do the same thing. at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. ed/sed are powerful languages that are used for 'changing' data, not searching it.. it _can_ be used to search but it's very heavy for the task. grep also searches content of files recursively, where as find does not, having find do it means forking the process and being very heavy also. cat and < are different in that one is a shell builtin and is used to.. concatonate files.. which the shell builtins do not do... ofc many people "use it wrong" but that's neither here nor there in this discussion. https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat
- simoncion 11y ago
  /me puts on Devil's Advocate hat > at runs a scheduled job once and then terminates, cron runs scheduled jobs repeatedly. Make recurring scheduled jobs reschedule themselves as their last action. This makes your job scheduler do one thing and do it well. :P > [ed] _can_ be used to search but it's very heavy for the task. So? ed was around before grep. Grep is therefore redundant. > grep also searches content of files recursively, where as find does not. The point there was that find can recursively create a list of files for grep to search, passing them along to grep. This means that grep's -r switch is redundant. /me removes Devil's Advocate hat > cat and < are different... If I had more time today, I would figure out if one can abuse the hell out of shell redirection to replace cat. It sounds like a fun way to waste a half-hour.

atombender 11y ago

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