3 ms·

Systemd is a pretty neat little thing. It's what keeps me running Ubuntu and Debian servers instead of switching to Alpine, at least in those situations where I

Systemd is a pretty neat little thing. It's what keeps me running Ubuntu and Debian servers instead of switching to Alpine, at least in those situations where I can't containerize what I want to do. The thing that got me into it was systemd timers. I really like being able to split up what should run from when should it run. `cron` works best if you desire simplicity above all else, and Slack used `cron` for a very long time before moving to something more custom. But I ultimately don't feel like the learning curve for systemd timers is that bad, and the benefits it can bring (like writing all your echo statements to journalctl instead of some random hard coded logfile in a script) feel very worth it to me.

charcircuit 3y ago
>`cron` works best if you desire simplicity above all else It may be simple, but it's config file is hard to comprehend compared to a systemd timer. Being able to just use "Friday 17:00" or "hourly" is so much more readable.
- hashworks 3y ago
  While I support systemd timers over cron, AFAIK cron has stuff like @hourly.
  - caiusdurling 3y ago
    Some cron implementations do, it's not portable.
    - bheadmaster 3y ago
      Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
      - dale_glass 3y ago
        What do you mean? There's a single implementation as far as I know, deployed on many distributions and working identically.
        bheadmaster 3y ago
        > There's a single implementation as far as I know That's exactly what I mean. Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.
        yau8edq12i 3y ago
        I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.
        bheadmaster 3y ago
        Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
        cjaybo 3y ago
        I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo. Do you take portable to mean a program that can run on every processor arch and OS available?
        bheadmaster 3y ago
        > Do you take portable to mean a program that can run on every processor arch and OS available? The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment). Let's take the context into account: > hashworks: While I support systemd timers over cron, AFAIK cron has stuff like @hourly. > caiusdurling: Some cron implementations do, it's not portable. > bheadmaster: Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface. User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly. However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.
  - cuu508 3y ago
    systemd also has shorthands like "hourly": https://www.man7.org/linux/man-pages/man7/systemd.time.7.html#CALENDAR_EVENTS https://www.man7.org/linux/man-pages/man7/systemd.time.7.htm... The man page lists: minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually (and "annually" further down in examples). It doesn't have a "hourly" directory where you can drop in scripts though, AFAIK.
  - dmd 3y ago
    And SLURM's scrontab has @fika, @teatime, and - as of yesterday - @elevenses.
- hiAndrewQuinn 3y ago
  I started writing a "oh, I never found it that difficult" comment. Then I thought to test my own belief and tried to type out a cron schedule for "run this every hour", and... Well... https://crontab.guru/#*_0/1_*_*_ https://crontab.guru/#*_0/1_*_*_* Oops. Point taken :)
  - js2 3y ago
    Run this every hour is: 0 * * * * this Adjust the leading digit to whichever minute of the hour you wish to run this.
  - Karellen 3y ago
    As well as the already-mentioned `n * * * *` solution, there's also dropping a symlink in /etc/cron.hourly to the program to run. Or a 2-line shell script if you need to add command-line params. (The other line is the shebang.)
    - js2 3y ago
      The cron.hourly directory is a non-standard Linux concept provided by run-parts. The FreeBSD equivalent is periodic, but that's really for system tasks and doesn't have anything more granular than daily.
      - Karellen 3y ago
        Yeah, but the comparison was specifically comparing to systemd timers, so I'm pretty sure the GP wasn't considering non-Linux compatibility anyway.
- lloeki 3y ago
  Debugging and tracability is just nuts too. With a timer and a run-once service it's easy to see what happens, happened, and will happen: systemctl status foo.timer tells you when it has last triggered and when it will triggered next, if it is still enabled. systemctl status foo.service tells you if it has been triggered from the timer and when, or ran manually with start I get the conceptual utter simplicity of cron in place of timer + a script in place of service but in practice systemd is much simpler and more consistent to manage.
  - pnutjam 3y ago
    Exactly, and there are still alot of old school "cron" users who don't touch the better "anacron" processes. I hate managing that stuff. Systemd > Anacron > Cron
    - lloeki 3y ago
      > a lot of old school "cron" users who don't touch the better "anacron" processes You're touching on something subtle where, like markdown, all cron look the same until they differ.
    - arminiusreturns 3y ago
      Even worse, when I was finding "crons" run from Java apps with cron4j. I hated on SystemD a lot in the early days, and there are still many legit criticisms that don't have good answers, but I have come to appreciate it's power and usefulness very much. Writing your own units seems so much cleaner than the old way, and I say that as a everyday bash script writer/user. (example, systemd-nspawn for containerization) PS: mcron is what I have been tinkering with and think will probably replace my systemd timers for most purposes. https://www.gnu.org/software/mcron/manual/mcron.html#Introduction https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...
- mrweasel 3y ago
  I also enjoy that you can ask systemd to validate your timer/cron, in case you struggle with the syntax: systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00"
girvo 3y ago
journalctl alone makes it so good IMO
jamesponddotco 3y ago
As a sysadmin, sandboxing and the general ease of use is what really sold systemd to me.

charcircuit 3y ago

>`cron` works best if you desire simplicity above all else It may be simple, but it's config file is hard to comprehend compared to a systemd timer. Being able to just use "Friday 17:00" or "hourly" is so much more readable.

hashworks 3y ago
While I support systemd timers over cron, AFAIK cron has stuff like @hourly.
- caiusdurling 3y ago
  Some cron implementations do, it's not portable.
  - bheadmaster 3y ago
    Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface.
    - dale_glass 3y ago
      What do you mean? There's a single implementation as far as I know, deployed on many distributions and working identically.
      - bheadmaster 3y ago
        > There's a single implementation as far as I know That's exactly what I mean. Systemd itself, including timers, is deeply coupled with the Linux API, and cannot be (easily) ported on any other system. Cron, on the other hand, exists on almost every UNIX-like system.
        yau8edq12i 3y ago
        I'm sure the few people who run BSD systems will be fine with cron's arcane syntax.
        bheadmaster 3y ago
        Portable has a well-defined meaning. You can argue that no other system matters (which I strongly disagree with for reasons I don't want to get into right now), but that doesn't make systemd timers any more portable.
        cjaybo 3y ago
        I’d argue that the degree of portability implied by the term is very much context dependent. “Portable between Linux systems” is a perfectly valid use of the term, imo. Do you take portable to mean a program that can run on every processor arch and OS available?
        bheadmaster 3y ago
        > Do you take portable to mean a program that can run on every processor arch and OS available? The definition of the word "portable" is not the point of this comment thread (although if you want to hear my definition, see the reply to a sibling comment). Let's take the context into account: > hashworks: While I support systemd timers over cron, AFAIK cron has stuff like @hourly. > caiusdurling: Some cron implementations do, it's not portable. > bheadmaster: Neither are systemd timers. I don't think there's a single system out there implementing the systemd timer interface. User caiusdurling said @hourly is not portable between cron implementations as a way to discredit hashworks' argument about cron having @hourly. However, that's a disingenious argument, because systemd timers aren't any more portable than cron implementations that use @hourly - in fact, there isn't a single system out there implementing the systemd timer interface except systemd.
- cuu508 3y ago
  systemd also has shorthands like "hourly": https://www.man7.org/linux/man-pages/man7/systemd.time.7.html#CALENDAR_EVENTS https://www.man7.org/linux/man-pages/man7/systemd.time.7.htm... The man page lists: minutely, hourly, daily, monthly, weekly, yearly, quarterly, semiannually (and "annually" further down in examples). It doesn't have a "hourly" directory where you can drop in scripts though, AFAIK.
- dmd 3y ago
  And SLURM's scrontab has @fika, @teatime, and - as of yesterday - @elevenses.
hiAndrewQuinn 3y ago
I started writing a "oh, I never found it that difficult" comment. Then I thought to test my own belief and tried to type out a cron schedule for "run this every hour", and... Well... https://crontab.guru/#*_0/1_*_*_ https://crontab.guru/#*_0/1_*_*_* Oops. Point taken :)
- js2 3y ago
  Run this every hour is: 0 * * * * this Adjust the leading digit to whichever minute of the hour you wish to run this.
- Karellen 3y ago
  As well as the already-mentioned `n * * * *` solution, there's also dropping a symlink in /etc/cron.hourly to the program to run. Or a 2-line shell script if you need to add command-line params. (The other line is the shebang.)
  - js2 3y ago
    The cron.hourly directory is a non-standard Linux concept provided by run-parts. The FreeBSD equivalent is periodic, but that's really for system tasks and doesn't have anything more granular than daily.
    - Karellen 3y ago
      Yeah, but the comparison was specifically comparing to systemd timers, so I'm pretty sure the GP wasn't considering non-Linux compatibility anyway.
lloeki 3y ago
Debugging and tracability is just nuts too. With a timer and a run-once service it's easy to see what happens, happened, and will happen: systemctl status foo.timer tells you when it has last triggered and when it will triggered next, if it is still enabled. systemctl status foo.service tells you if it has been triggered from the timer and when, or ran manually with start I get the conceptual utter simplicity of cron in place of timer + a script in place of service but in practice systemd is much simpler and more consistent to manage.
- pnutjam 3y ago
  Exactly, and there are still alot of old school "cron" users who don't touch the better "anacron" processes. I hate managing that stuff. Systemd > Anacron > Cron
  - lloeki 3y ago
    > a lot of old school "cron" users who don't touch the better "anacron" processes You're touching on something subtle where, like markdown, all cron look the same until they differ.
  - arminiusreturns 3y ago
    Even worse, when I was finding "crons" run from Java apps with cron4j. I hated on SystemD a lot in the early days, and there are still many legit criticisms that don't have good answers, but I have come to appreciate it's power and usefulness very much. Writing your own units seems so much cleaner than the old way, and I say that as a everyday bash script writer/user. (example, systemd-nspawn for containerization) PS: mcron is what I have been tinkering with and think will probably replace my systemd timers for most purposes. https://www.gnu.org/software/mcron/manual/mcron.html#Introduction https://www.gnu.org/software/mcron/manual/mcron.html#Introdu...
mrweasel 3y ago
I also enjoy that you can ask systemd to validate your timer/cron, in case you struggle with the syntax: systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00"

girvo 3y ago

journalctl alone makes it so good IMO

jamesponddotco 3y ago

As a sysadmin, sandboxing and the general ease of use is what really sold systemd to me.