8 ms·

Nice overview. UX wise systemd timers are far superior.

krupan 2y ago
Are they though? Last time I played with them I had to create/edit two text files instead of one (service file and timer file), figure out if I needed to enable and start them both, figure out what to do if I want to temporarily disable the timer (systemctl stop? disable?), etc.
- pkulak 2y ago
  That’s true. But once you get it set up, you can check the status, see when it last ran, when it will run next, the logs from the last run, if it failed last time, why, etc. You can stop it, start it, restart it, disable it. Simeone just needs to write some CLI for making really simple timers.
  - johnchristopher 2y ago
    > Simeone just needs to write some CLI for making really simple timers. That's a post-it or a simple-systemd-timers.txt though. Don't bother Simeone with that :).
    - pkulak 2y ago
      lol. I must have been on mobile.
  - fragmede 2y ago
    Open a terminal and then in bash: while true; do date; ./doit.sh; sleep 300; done | tee doit.log if you want to get fancy, you can do: date "+%Y.%M.%dT%H:%m:%s-%Z`./doit.sh`" to get it all on one line.
    - zitsarethecure 2y ago
      For doing things like this I like using the "watch" command.
    - fodkodrasz 2y ago
      Yeah, it is almost at feature parity. The following bloat is not needed at all: 1. Ensure commands are ran after you close the terminal you just opened. 2. Trigger actions when the process did fail (OnFailure=) 3. ensure the scheduling job survives system restarts 4. have proper scheduling, and handling of missed schedule doe to downtime (eg. for notebooks) 5. run the process in cgoups, under other user's context, or in a chroot, etc. 6. apply randomized jitter to the schedule to avoid crating overload and cascading failures resulting from that 7. Timing out tasks 8. Handle service dependencies... just to name few from the top of my head... cron is great, and systemd timers are also good, and even more refined solution to the task scheduling problem. Your propsal does not solve even the basics (configurable schedule). As other comment notes your script is more like the watch command.
  - MrDrMcCoy 2y ago
    Don't forget one of the best reasons timers are great: they won't cause long-running jobs to overlap. I can't tell you how many systems I've had to unbreak because a job took too long and spiraled out of control.
- BossingAround 2y ago
  Which is much easier than fiddling around with crontab, in my experience. Yes, you need a systemd service file and a systemd timer file. Creating both is a matter of ~30m. Then, you do `systemctl start` and you're good... As a great benefit, you can see the status of each timer, which is great for debugging quick problems, like permission issues/runtime errors/... when setting the timer up.
  - SSLy 2y ago
    start and enable, or they won't come up after reboot or target change
    - deleted 2y ago
      [deleted]
    - vaylian 2y ago
      Handy shortcut: systemctl enable foo.timer --now To enable and start the unit in one command.
  - sgarland 2y ago
    > Creating both is a matter of ~30m. I can write a cron entry in a minute or two, depending on the complexity.
    - BossingAround 2y ago
      Well, it takes 30m the first time, when learning from scratch. When learning the arcane cron entry system, I'd guess it takes even longer than 30m, unless you have a simple time in mind (like "every minute" or something similar - "every second Monday" is definitely more complex to reason about in cron). Again, comparing not knowing systemd timer vs not knowing cron.
      - sgarland 2y ago
        Sure, not saying you can just sit down and do it straight away. But the additional complexity of systemd, I think, makes it even more daunting. It’s much like how modern frontend has a million components. I understand there are or were reasons for all of it, but not everyone needs it, and it’s intimidating to a newcomer. In comparison, cron (and *nix tooling in general) asks you to learn a small bit of that tool’s syntax, and that’s it. You can add complexity if you’d like – read the man pages – but for the most part, you can be productive very quickly.
- rawoke083600 2y ago
  Can't agree more ! Having multiple files is almost never good for these types of things.
- bravetraveler 2y ago
  Yes if you actually engage and stop playing helpless. The system established things one shouldn't have had to do for decades.
- crabbone 2y ago
  Yeah. You get as a bonus a lot of generic tools that work with systemd like journald and other systemd-family utilities. This allows you to log, group jobs, investigate failures, all with better ergonomics and easily transform it into production-grade automation, if necessary. There's really no reason to use cron today if you have systemd.
  - sgarland 2y ago
    I feel like I’m taking crazy pills. “A lot of other generic tools?” You mean like how every *nix tool works for crons, because they’re text files, and *nix tooling operates on text files? There’s a huge reason to use cron: it’s dead simple, doesn’t require a ton of complexity around it to function, and the syntax hasn’t changed in decades.
    - crabbone 2y ago
      No, I don't mean like how every *nix tool works. I mean tools that are specifically designed to work with the data generated and stored by systemd. To give some examples: stdout from the process ran by systemd is automatically collected, timestamped, rotated and interactively paged by journald. journald in turn allows various filtering of the stored logs. On top of this, systemd can be configured to aggregate logs over networks of computers. It has exporters into popular log databases that allow for easy integration with other data collection tools. In a sense, you could say that Unix shell, or other tools like pipes or redirects constitute an interface that allows generic cooperation between tools written without knowledge of the other tools. So, you aren't too far off. However, the tradeoff here is that with very few very generic tools you must give up more complex things. Eg. you have to concede that everything is a string. When you can confine the interfaces to a smaller group of tools, you can take better advantage of the data they communicate (eg. compared to passing data through pipes, where you have to serialize to string and parse from string data that isn't inherently a string, you can work with structured data with many useful types). > There’s a huge reason to use cron: it’s dead simple systemd timers are still simpler. I.e. cron isn't complicated, but it has too many tools all over the place, many arbitrary conventions, its failures are difficult to diagnose. And it's OK. It was written at the time nobody even thought about systemd, so, they had to do some of that work themselves. Today, it's just an anachronism ;)
scrapheap 2y ago
Maybe if everyone on your team naturally uses systemd timers, but if they instinctively reach for cron then it's UX will be far superior for them.

Are they though? Last time I played with them I had to create/edit two text files instead of one (service file and timer file), figure out if I needed to enable and start them both, figure out what to do if I want to temporarily disable the timer (systemctl stop? disable?), etc.

pkulak 2y ago
That’s true. But once you get it set up, you can check the status, see when it last ran, when it will run next, the logs from the last run, if it failed last time, why, etc. You can stop it, start it, restart it, disable it. Simeone just needs to write some CLI for making really simple timers.
- johnchristopher 2y ago
  > Simeone just needs to write some CLI for making really simple timers. That's a post-it or a simple-systemd-timers.txt though. Don't bother Simeone with that :).
  - pkulak 2y ago
    lol. I must have been on mobile.
- fragmede 2y ago
  Open a terminal and then in bash: while true; do date; ./doit.sh; sleep 300; done | tee doit.log if you want to get fancy, you can do: date "+%Y.%M.%dT%H:%m:%s-%Z`./doit.sh`" to get it all on one line.
  - zitsarethecure 2y ago
    For doing things like this I like using the "watch" command.
  - fodkodrasz 2y ago
    Yeah, it is almost at feature parity. The following bloat is not needed at all: 1. Ensure commands are ran after you close the terminal you just opened. 2. Trigger actions when the process did fail (OnFailure=) 3. ensure the scheduling job survives system restarts 4. have proper scheduling, and handling of missed schedule doe to downtime (eg. for notebooks) 5. run the process in cgoups, under other user's context, or in a chroot, etc. 6. apply randomized jitter to the schedule to avoid crating overload and cascading failures resulting from that 7. Timing out tasks 8. Handle service dependencies... just to name few from the top of my head... cron is great, and systemd timers are also good, and even more refined solution to the task scheduling problem. Your propsal does not solve even the basics (configurable schedule). As other comment notes your script is more like the watch command.
- MrDrMcCoy 2y ago
  Don't forget one of the best reasons timers are great: they won't cause long-running jobs to overlap. I can't tell you how many systems I've had to unbreak because a job took too long and spiraled out of control.
BossingAround 2y ago
Which is much easier than fiddling around with crontab, in my experience. Yes, you need a systemd service file and a systemd timer file. Creating both is a matter of ~30m. Then, you do `systemctl start` and you're good... As a great benefit, you can see the status of each timer, which is great for debugging quick problems, like permission issues/runtime errors/... when setting the timer up.
- SSLy 2y ago
  start and enable, or they won't come up after reboot or target change
  - deleted 2y ago
    [deleted]
  - vaylian 2y ago
    Handy shortcut: systemctl enable foo.timer --now To enable and start the unit in one command.
- sgarland 2y ago
  > Creating both is a matter of ~30m. I can write a cron entry in a minute or two, depending on the complexity.
  - BossingAround 2y ago
    Well, it takes 30m the first time, when learning from scratch. When learning the arcane cron entry system, I'd guess it takes even longer than 30m, unless you have a simple time in mind (like "every minute" or something similar - "every second Monday" is definitely more complex to reason about in cron). Again, comparing not knowing systemd timer vs not knowing cron.
    - sgarland 2y ago
      Sure, not saying you can just sit down and do it straight away. But the additional complexity of systemd, I think, makes it even more daunting. It’s much like how modern frontend has a million components. I understand there are or were reasons for all of it, but not everyone needs it, and it’s intimidating to a newcomer. In comparison, cron (and *nix tooling in general) asks you to learn a small bit of that tool’s syntax, and that’s it. You can add complexity if you’d like – read the man pages – but for the most part, you can be productive very quickly.
rawoke083600 2y ago
Can't agree more ! Having multiple files is almost never good for these types of things.
bravetraveler 2y ago
Yes if you actually engage and stop playing helpless. The system established things one shouldn't have had to do for decades.
crabbone 2y ago
Yeah. You get as a bonus a lot of generic tools that work with systemd like journald and other systemd-family utilities. This allows you to log, group jobs, investigate failures, all with better ergonomics and easily transform it into production-grade automation, if necessary. There's really no reason to use cron today if you have systemd.
- sgarland 2y ago
  I feel like I’m taking crazy pills. “A lot of other generic tools?” You mean like how every *nix tool works for crons, because they’re text files, and *nix tooling operates on text files? There’s a huge reason to use cron: it’s dead simple, doesn’t require a ton of complexity around it to function, and the syntax hasn’t changed in decades.
  - crabbone 2y ago
    No, I don't mean like how every *nix tool works. I mean tools that are specifically designed to work with the data generated and stored by systemd. To give some examples: stdout from the process ran by systemd is automatically collected, timestamped, rotated and interactively paged by journald. journald in turn allows various filtering of the stored logs. On top of this, systemd can be configured to aggregate logs over networks of computers. It has exporters into popular log databases that allow for easy integration with other data collection tools. In a sense, you could say that Unix shell, or other tools like pipes or redirects constitute an interface that allows generic cooperation between tools written without knowledge of the other tools. So, you aren't too far off. However, the tradeoff here is that with very few very generic tools you must give up more complex things. Eg. you have to concede that everything is a string. When you can confine the interfaces to a smaller group of tools, you can take better advantage of the data they communicate (eg. compared to passing data through pipes, where you have to serialize to string and parse from string data that isn't inherently a string, you can work with structured data with many useful types). > There’s a huge reason to use cron: it’s dead simple systemd timers are still simpler. I.e. cron isn't complicated, but it has too many tools all over the place, many arbitrary conventions, its failures are difficult to diagnose. And it's OK. It was written at the time nobody even thought about systemd, so, they had to do some of that work themselves. Today, it's just an anachronism ;)

scrapheap 2y ago

Maybe if everyone on your team naturally uses systemd timers, but if they instinctively reach for cron then it's UX will be far superior for them.