5 ms·

> cron ... absorbed by the systemd borg This has already happened, right? https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.

> cron ... absorbed by the systemd borg This has already happened, right? https://wiki.archlinux.org/index.php/Systemd/Timers https://wiki.archlinux.org/index.php/Systemd/Timers Not a systemd fan, myself.

SahAssar 8y ago
IMO cron is one of the parts that a good process management system should solve. With systemd timers I can do stuff like require other processes to run for a timer to run, activate a process either on a timer or on a socket, specify that it runs in a private chroot/netns/cgroup. These are all common things that I might usually want a process or service to do, and putting timed, manual, socket and path invocation of a service in the process management system makes sense to me. I understand some of the systemd criticism, but I don't at all understand why you want something else to manage your processes than the process management system (which is basically always the init system)?
- mmt 8y ago
  > I understand some of the systemd criticism, but I don't at all understand why you want something else to manage your processes than the process management system (which is basically always the init system)? Perhaps you don't understand one of the fundamental, philosophical criticisms, which is that it violates the Unix tenet of "do one thing and one thing well". Timing, and scheduling are difficult and (arguably, of course), deserve their own, separate utility. Cron isn't a process manager, any more than and interactive shell [1]. It just starts processes (and passes output to a local email client, though that's, understandably, brittle). I wouldn't object to moving the process-starting functionality out of cron and leaving it with only the ability to tell init to "start job named XYZ", but I do object to just integrating its core competency of scheduling into that init. [1] Arguably less than, considering modern shells' job control and signal facilities

SahAssar 8y ago

IMO cron is one of the parts that a good process management system should solve. With systemd timers I can do stuff like require other processes to run for a timer to run, activate a process either on a timer or on a socket, specify that it runs in a private chroot/netns/cgroup. These are all common things that I might usually want a process or service to do, and putting timed, manual, socket and path invocation of a service in the process management system makes sense to me. I understand some of the systemd criticism, but I don't at all understand why you want something else to manage your processes than the process management system (which is basically always the init system)?

mmt 8y ago
> I understand some of the systemd criticism, but I don't at all understand why you want something else to manage your processes than the process management system (which is basically always the init system)? Perhaps you don't understand one of the fundamental, philosophical criticisms, which is that it violates the Unix tenet of "do one thing and one thing well". Timing, and scheduling are difficult and (arguably, of course), deserve their own, separate utility. Cron isn't a process manager, any more than and interactive shell [1]. It just starts processes (and passes output to a local email client, though that's, understandably, brittle). I wouldn't object to moving the process-starting functionality out of cron and leaving it with only the ability to tell init to "start job named XYZ", but I do object to just integrating its core competency of scheduling into that init. [1] Arguably less than, considering modern shells' job control and signal facilities