13 ms·

Systemd.timer, an Alternative to Cron

84 points by bkq 4y ago

whateveracct 4y ago
I quite like systemd timers with NixOS (configured in the Nix language). They've become a standard hammer for me.
- superkuh 4y ago
  Nix/Guix users would think that way. They've alrady given up on the concept of system libraries or a unified OS. systemd's writing of 2 config files per timer would be right at home for people that have to set up an entire OS environment every time they want to try to compile something somone else hasn't already written a nix script for.
  - ravi-delia 4y ago
    This would be needlessly insulting if it were posted as a top level comment, but as a direct reply to a Nix user it is impossible to read as anything other than the worst of condescension. Can you really say this is a net improvement to the tone of the conversation in this thread?
    - Arnavion 4y ago
      Wouldn't be a systemd thread without shitposting in every other comment. Just flag and move on.
    - superkuh 4y ago
      I'm responding to a Nix user making this about how Nix does timing. I'm relating it to the common thread of cargo cult'ing shared between systemd and users of Nix as desktop operating systems. They both increase the amount of config files necessary to accomplish what should be almost config-less tasks and spread those config files out across many places instead of a single config store that is for the entire OS. It's bad policy for desktops even if it's good for you in work environments and so you use it anyway. Normalizing that is bad. I said it like a jerk though. Sorry.
      - whateveracct 4y ago
        Nix does have a single config that defines the entire OS though! Which seems to be what you want? It has imports I suppose but still.
  - civopsec 4y ago
    Roger that. Did that feel cathartic?
  - whateveracct 4y ago
    Joke's on you! Nix allows abstraction, so I just have a function mkTimer name schedule program and it Just Works. You can even inline a bash script in the program argument if you want.
- mongol 4y ago
  Systemd and NixOS feels like a great fit. It is easier to configure than the real thing and also short scripts are easier to tie together with services and timers. All in one file instead of 2 or 3.
traverseda 4y ago
https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a crontab to see when things will next execute, run some other tool that will inspect everything for you. Make things more complex and difficult to read, and then write tools to make it easier to read again. They could have just added "periodic" service type that accepts timer options, and at least then it wouldn't have to be two files. Most of the advantages really don't seem like advantages to me. Templated unit files seems especially silly since it's equivalent to just copy and pasting a line in your crontab and changing an argument. Seems to work for a lot of people, it's just not to my tastes I guess. Still, I find the whole thing pretty mystifying.
- aidenn0 4y ago
  NixOS fortunately solves this problem. Here's a daily rsync with some names changed to protect any innocent hosts on my network. Note that the contents of "sync.sh" could easily go in there as well, but I was previously running it via cron, so didn't bother to move that over. systemd.services.somehost-sync = { startAt = "daily"; path = [ pkgs.coreutils pkgs.rsync pkgs.openssh ]; environment = { HOME = "/home/someuser"; }; script = ''/external/media/sync.sh''; serviceConfig.User = "someuser"; }; Not everything in NixOS has been a "win" but systemd timers are so much more ergonomic under nix
- ghostpepper 4y ago
  Binary log files is another example of something that could have advantages in theory but never seems to work well in practice. What used to be "tail /var/log/nginx.log" is now man journalctl journalctl -u nginx <G to skip to latest, ctrl+C because it's taking too long> journalctl | grep nginx <wait...> go back to man page to look for more options to search etc
  - traverseda 4y ago
yamtaddle 4y ago
The one time I've tried to use this in anger, it said my script was running when it was supposed to and exiting cleanly, everything green, but nothing was happening. Put it in cron, worked first try, and forgot about it.
sparker72678 4y ago
You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.
- bigpeopleareold 4y ago
  I seemed to never care until they took my sysvinit away (or maybe any decent init system :D). Then they took resolv.conf control away. Then when I shutdown my computer, some random process takes 1 min 30 seconds to shutdown when it probably doesn't need to. Then I read on hacker news recently that Fedora uses a systemd daemon for handling OOM and the writer said it was terribly misconfigured particularly when it shutdown his X session and all processes related to it when an OOM condition happened. I am not a Linux admin (or at least a sophisticated one so I can look smart with systemd), but now they are taking cron away too? :D I kid about this, in a way, and I know I should accept the inevitable, but I feel like just moving to Devuan on my laptop and use a nice init system, like OpenRC :D
  - chasil 4y ago
    Use "halt -fp" if you want to bring your system down in a hurry. It's best to shut down any databases prior to this.
  - yawaramin 4y ago
    'Terribly misconfigured' sounds like a bug report should be filed at the distro level, not a complaint about the upstream tool on HN ;-)
    - bigpeopleareold 4y ago
      Hopefully the author did that :) https://news.ycombinator.com/item?id=33894469 https://news.ycombinator.com/item?id=33894469
- eulers_secret 4y ago
  This is exactly what happens, just like the old XKCD: Now there are N+1 competing standards. It's why I have to check /etc/profile, ~/.profile, /etc/profile.d/*, ~/.bashrc (or whatever shell), /etc/environment, ~/.env, and a few others I don't even remember to figure out why an $ENVVAR is set. I have to look at two cron-like things to figure out what's scheduled when. systemd-timers has been around and in use for a long while.
pm90 4y ago
I've had the opportunity to delve into systemd in a previous role. This sounds a bit weird, but its not easy to get started with, unless you're used to reading man pages. But once you're able to read man pages, all of systemd behavior is documented in the man pages. I do wish there were more human friendly docs though, especially for younger engineers used to better sorts of docs. Anyways, once you do get the hang of it, its an immensely powerful system, but like any such system it has its quirks and edge cases. You can get 99% of what you need with it though, and for low level tasks on machines, its pretty amazing.
- dinosaurdynasty 4y ago
  systemd has amazing documentation, you just have to read them...
  - egberts1 4y ago
    I think a link prominently placed on their website would be helpful. Also systemd documentation isn't compliance with: * Tutorial * Explaination * How To * Reference For instance, I want to know which part of systemd uses `SYSTEMD_DEBUG`. Hold on ... I am digging thru the Git repo. Screw the systemd manual: Here's my environment variable reference guide for debugging systemd (that is NOT documented by systemd) https://egbert.net/blog/articles/debugging-a-service-in-systemd.html https://egbert.net/blog/articles/debugging-a-service-in-syst...
    - mariusor 4y ago
      > I think a link prominently placed on their website would be helpful. It's such a weird disconnect seeing people that can't go outside of the mindset that everything is a web application. Systemd ships their documentation (most of what you asked for, actually) with the package, and their environment variables description can be found in /usr/share/doc/systemd/ENVIRONMENT.md (at least on my machine). When you're dealing with the applications which form the building blocks of a *nix environment your first step should not be google, but grepping through the /usr/share/doc, and using the apropos and man commands.
mnd999 4y ago
How long until we get the systemd kernel?
- Gualdrapo 4y ago
  After we get systemd-antivirusd
- dale_glass 4y ago
  We do have systemd-boot! And it's not half-bad, I think, because GRUB2 is just way, way more complicated than most setups need these days.
deleted 4y ago
[deleted]
ciupicri 4y ago
I don't get the first argument. Put the whole command in a shell script and be done with it. You can easily run it anytime you want to. Same with the last - templated unit files. Add a parameter or more to the script and you're done.
dig1 4y ago
When I set up a new box, the first thing I do is disable all sorts of systemd-* nonsense, keeping systemd as an initd service only (which it should be). Then I replace them with serious, battle-tested tools like ntp/chrony, unbound, etc... It looks like systemd.timer will continue this practice ;) I'm expecting someone at Canonical/IBM/RH will be happy to put this as the default scheduler in the next distro release, marking it as a "significant improvement".
luckycharms810 4y ago
While I agree Systemd timers aren't as ergonomic to set up - there are some benefits that I would basically never give up at this point. * Running the service on command ( this is the best way to troubleshoot issues with your slightly different environments / cron's version of shell. I've spent many minutes over my career - setting the crontab one minute and the future and waiting for it to run / fail ) * Easily inspecting when the next run of the service is. ( list-timers ) * Straightforward access to the logs ( Always journalctl ) * Specifying environment variables easily * OnFailure
- jamespwilliams 4y ago
  * Built in locking (so you don't need to worry about two instances of your cron running at the same time) * Built in functionality for telling when the cron last ran, and whether it was successful or not (so you can do alerting) * Ability to specify human-readable schedules * Built-in feature for randomising cron start time to avoid stampeding
  - klodolph 4y ago
    The built-in locking is IMO a big deal. If you have a script that you run every 24 hours, what happens when it takes 25 hours to complete? (My experience is that this happens only years later, and the people who wrote the cronjob are gone.)
- mike_hearn 4y ago
  Speaking on OnFailure, one of the unfortunate aspects of systemd timers (which are otherwise quite nice) is you need to do extra work to get proper emails when something fails. Here's how I do this: Define email-unit-status@.service [Unit] Description=Email status for %i to root After=network.target [Service] Type=oneshot ExecStart=email-unit-status %i Define email-unit-status (a script) #!/usr/bin/env bash set -eu dest="admin@whatever.com" userflag= if [[ $HOME == /home/* ]]; then userflag=--user fi html=$(SYSTEMD_COLORS=1 systemctl $userflag status --full "$1" | ansi2html -w -c) /usr/sbin/sendmail -t <<ERRMAIL To: $dest From: systemd <${USER}@${HOSTNAME}> Subject: SystemD unit failure alert: $1 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=UTF-8 Mime-Version: 1.0 $html ERRMAIL Then you can add to a service: OnFailure=email-unit-status@%n You will need to install the ansi2html tool. This stuff should come with systemd really.
karlicoss 4y ago
Some time ago I wanted the best bits from both worlds: - from cron: specifying all jobs in one file instead of scattering it across dosens of unit files. In 90% of cases I just want a regular schedule and the command, that's it - from systemd: mainly monitoring and logging. But also flexible timers, timeouts, resource management, dependencies -- for the remaining 10% of jobs which are a little more complicated So I implemented a DSL which basically translates a python spec into systemd units -- that way I don't have to remember systemd syntax and manually manage the unit files. At the same time I benefit from the simplicity of having everything in one place. An extra bonus is that the 'spec' is just normal python code - you can define variables/functions/loops to avoid copy pasting - you can use mypy to lint it before applying the changes - I have multiple computers that share some jobs, so I simply have a 'common.py' file which I import from `computer1.py` and `computer2.py` -- the whole thing is very flexible. You can read more about it here: - https://beepb00p.xyz/scheduler.html https://beepb00p.xyz/scheduler.html - https://github.com/karlicoss/dron#what-does-it-do https://github.com/karlicoss/dron#what-does-it-do I've been using this tool for several year now, with hundreds of different jobs across 3 computers, and it's been working perfectly for me. One of the best quality of life improvements I've done for my personal infrastructure.
smm11 4y ago
- dale_glass 4y ago
  I never quite understood that criticism, since systemd is extremely unapologetically Linux centric. It uses all the cool features of the kernel. It's configured with text files, and has an override system that works great with the Linux filesystem layout and package manager -- much better than SysV init, by the way. And it handles a lot of little annoyances that have long been a thorn in an admin's/user's side on Linux.
  - ThatGeoGuy 4y ago
    Some parts are extremely Linux-centric. I'd argue the better parts of systemd (it's not all bad but there's a lot of low-hanging fruit for all of us to gripe and bicker about) are the imaginings that came from launchd. That for sure was more UNIX centric than "linux" in particular. You're right that the criticism "just become windows" seems weird - if anything else one should just say "get a mac" since that's where a lot of the launchd ideas originated.
    - dale_glass 4y ago
      I mean, systemd makes heavy use of Linux-only APIs. For instance it's very reliant on cgroups, a Linux-only feature. The main project rejects even trying to be portable. This ensures there's no such thing as accounting for that some feature might not work on FreeBSD, because the project just clearly states that it won't be a thing on *BSD.
- jeroenhd 4y ago
  God, I wish Linux would copy more Windows features. Service management before systemd was a hell of intermingled shell scripts (that often specified sh but only ran on bash) and side effects everywhere. Cron is a very stable tool but it should've been replaced when the first GUI ran on Linux. I don't understand this idolisation of 70s mainframes that "hardcore" Linux users all seem to fight for. Systemd features can all be turned off if you want them to, but every day more and more alternatives go into maintenance mode because nobody uses them anymore. Inetdwas great when it was invented but we've moved past that point more than ten years ago. When I'm tinkering, I love the great hacks I can apply by modifying system shell scripts, but I mostly just want my computers to work for me. The old ways of randomly placed dot files, custom service scripts (and formats) and modifying scripts that I shouldn't need to ever touch anyway because they conflict with another cobbled together script have caused me more headaches than systemd ever has. I wish system's docs were easier to find, but even the obscure man page names are better than comments in bash scripts somewhere in /etc/init.d.
tb_technical 4y ago
Why? Crob is simple, well understood, and works well. Why in god's name do you want to reinvent the wheel?
- hulitu 4y ago
  Because is not round enough. This is a trend in SW: facelift every couple of years.
- yawaramin 4y ago
  How does it work if I want to ensure that a certain volume must be mounted before a job runs?
  - tb_technical 4y ago
    Add the check at the start of the script?
    - yawaramin 4y ago
      What check exactly? What's the command?
      - tb_technical 4y ago
        Try this, replace "/foo/bar" with the path to your mount point, and the echos with additional desired behaviour. (I'm assuming you're writing a bash script on a Linux system) if grep -qs '/foo/bar' /proc/mounts; then echo "/foo/bar mounted" else echo "/foo/bar not mounted" return 1 || exit 1 fi Put these commands below the shebang but before the start of the script. I hope this helps you! Edit: I added a crapload of newlines to better show the indentation and newlines required for the script to work. Sorry it's ugly
exabrial 4y ago
> Job output will automatically be written to systemd-journald This is a bad thing, not something I’d boast about. I actually really enjoy using systemd. Being able to start a process with complete isolation without heavyweight docker downloading mystery meat off the internet is a huge boon. However, one thing systemd is logging. Jounalctl sucks. Grep, cat, etc, work infinitesimally better.
- kaba0 4y ago
  You can redirect all your logs to traditional string-based ones if you want though.
  - exabrial 4y ago
    Precisely. That's exactly what we end up doing
- yawaramin 4y ago
  'Infinitesimally' means 'by a negligible amount'. Which is (accidentally) accurate. There's nothing preventing you from using grep, cat, etc. with the output of journalctl. It's just a tool in the pipeline.
deleted 4y ago
[deleted]

84 points by bkq 4y ago

whateveracct 4y ago

I quite like systemd timers with NixOS (configured in the Nix language). They've become a standard hammer for me.

superkuh 4y ago
Nix/Guix users would think that way. They've alrady given up on the concept of system libraries or a unified OS. systemd's writing of 2 config files per timer would be right at home for people that have to set up an entire OS environment every time they want to try to compile something somone else hasn't already written a nix script for.
- ravi-delia 4y ago
  This would be needlessly insulting if it were posted as a top level comment, but as a direct reply to a Nix user it is impossible to read as anything other than the worst of condescension. Can you really say this is a net improvement to the tone of the conversation in this thread?
  - Arnavion 4y ago
    Wouldn't be a systemd thread without shitposting in every other comment. Just flag and move on.
  - superkuh 4y ago
    I'm responding to a Nix user making this about how Nix does timing. I'm relating it to the common thread of cargo cult'ing shared between systemd and users of Nix as desktop operating systems. They both increase the amount of config files necessary to accomplish what should be almost config-less tasks and spread those config files out across many places instead of a single config store that is for the entire OS. It's bad policy for desktops even if it's good for you in work environments and so you use it anyway. Normalizing that is bad. I said it like a jerk though. Sorry.
    - whateveracct 4y ago
      Nix does have a single config that defines the entire OS though! Which seems to be what you want? It has imports I suppose but still.
- civopsec 4y ago
  Roger that. Did that feel cathartic?
- whateveracct 4y ago
  Joke's on you! Nix allows abstraction, so I just have a function mkTimer name schedule program and it Just Works. You can even inline a bash script in the program argument if you want.
mongol 4y ago
Systemd and NixOS feels like a great fit. It is easier to configure than the real thing and also short scripts are easier to tie together with services and timers. All in one file instead of 2 or 3.

traverseda 4y ago

https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy is split into two separate files? It's like that a lot in systemd, whoever is doing the architecture doesn't seem to understand why locality of behavior would be desirable, instead taking the IDE approach of writing a bunch of tools to make managing the increased complexity more manageable. Don't glance at a crontab to see when things will next execute, run some other tool that will inspect everything for you. Make things more complex and difficult to read, and then write tools to make it easier to read again. They could have just added "periodic" service type that accepts timer options, and at least then it wouldn't have to be two files. Most of the advantages really don't seem like advantages to me. Templated unit files seems especially silly since it's equivalent to just copy and pasting a line in your crontab and changing an argument. Seems to work for a lot of people, it's just not to my tastes I guess. Still, I find the whole thing pretty mystifying.

aidenn0 4y ago
NixOS fortunately solves this problem. Here's a daily rsync with some names changed to protect any innocent hosts on my network. Note that the contents of "sync.sh" could easily go in there as well, but I was previously running it via cron, so didn't bother to move that over. systemd.services.somehost-sync = { startAt = "daily"; path = [ pkgs.coreutils pkgs.rsync pkgs.openssh ]; environment = { HOME = "/home/someuser"; }; script = ''/external/media/sync.sh''; serviceConfig.User = "someuser"; }; Not everything in NixOS has been a "win" but systemd timers are so much more ergonomic under nix
ghostpepper 4y ago
Binary log files is another example of something that could have advantages in theory but never seems to work well in practice. What used to be "tail /var/log/nginx.log" is now man journalctl journalctl -u nginx <G to skip to latest, ctrl+C because it's taking too long> journalctl | grep nginx <wait...> go back to man page to look for more options to search etc
- traverseda 4y ago

yamtaddle 4y ago

The one time I've tried to use this in anger, it said my script was running when it was supposed to and exiting cleanly, everything green, but nothing was happening. Put it in cron, worked first try, and forgot about it.

sparker72678 4y ago

You can pry my crontab out of my cold, dead hands. Seriously, though, cron has been so utterly reliable for me for so many decades now, it will be really hard for me to ever give it up.

bigpeopleareold 4y ago
I seemed to never care until they took my sysvinit away (or maybe any decent init system :D). Then they took resolv.conf control away. Then when I shutdown my computer, some random process takes 1 min 30 seconds to shutdown when it probably doesn't need to. Then I read on hacker news recently that Fedora uses a systemd daemon for handling OOM and the writer said it was terribly misconfigured particularly when it shutdown his X session and all processes related to it when an OOM condition happened. I am not a Linux admin (or at least a sophisticated one so I can look smart with systemd), but now they are taking cron away too? :D I kid about this, in a way, and I know I should accept the inevitable, but I feel like just moving to Devuan on my laptop and use a nice init system, like OpenRC :D
- chasil 4y ago
  Use "halt -fp" if you want to bring your system down in a hurry. It's best to shut down any databases prior to this.
- yawaramin 4y ago
  'Terribly misconfigured' sounds like a bug report should be filed at the distro level, not a complaint about the upstream tool on HN ;-)
  - bigpeopleareold 4y ago
    Hopefully the author did that :) https://news.ycombinator.com/item?id=33894469 https://news.ycombinator.com/item?id=33894469
eulers_secret 4y ago
This is exactly what happens, just like the old XKCD: Now there are N+1 competing standards. It's why I have to check /etc/profile, ~/.profile, /etc/profile.d/*, ~/.bashrc (or whatever shell), /etc/environment, ~/.env, and a few others I don't even remember to figure out why an $ENVVAR is set. I have to look at two cron-like things to figure out what's scheduled when. systemd-timers has been around and in use for a long while.

pm90 4y ago

I've had the opportunity to delve into systemd in a previous role. This sounds a bit weird, but its not easy to get started with, unless you're used to reading man pages. But once you're able to read man pages, all of systemd behavior is documented in the man pages. I do wish there were more human friendly docs though, especially for younger engineers used to better sorts of docs. Anyways, once you do get the hang of it, its an immensely powerful system, but like any such system it has its quirks and edge cases. You can get 99% of what you need with it though, and for low level tasks on machines, its pretty amazing.

dinosaurdynasty 4y ago
systemd has amazing documentation, you just have to read them...
- egberts1 4y ago
  I think a link prominently placed on their website would be helpful. Also systemd documentation isn't compliance with: * Tutorial * Explaination * How To * Reference For instance, I want to know which part of systemd uses `SYSTEMD_DEBUG`. Hold on ... I am digging thru the Git repo. Screw the systemd manual: Here's my environment variable reference guide for debugging systemd (that is NOT documented by systemd) https://egbert.net/blog/articles/debugging-a-service-in-systemd.html https://egbert.net/blog/articles/debugging-a-service-in-syst...
  - mariusor 4y ago
    > I think a link prominently placed on their website would be helpful. It's such a weird disconnect seeing people that can't go outside of the mindset that everything is a web application. Systemd ships their documentation (most of what you asked for, actually) with the package, and their environment variables description can be found in /usr/share/doc/systemd/ENVIRONMENT.md (at least on my machine). When you're dealing with the applications which form the building blocks of a *nix environment your first step should not be google, but grepping through the /usr/share/doc, and using the apropos and man commands.

mnd999 4y ago

How long until we get the systemd kernel?

Gualdrapo 4y ago
After we get systemd-antivirusd
dale_glass 4y ago
We do have systemd-boot! And it's not half-bad, I think, because GRUB2 is just way, way more complicated than most setups need these days.

deleted 4y ago

[deleted]

ciupicri 4y ago

I don't get the first argument. Put the whole command in a shell script and be done with it. You can easily run it anytime you want to. Same with the last - templated unit files. Add a parameter or more to the script and you're done.

dig1 4y ago

When I set up a new box, the first thing I do is disable all sorts of systemd-* nonsense, keeping systemd as an initd service only (which it should be). Then I replace them with serious, battle-tested tools like ntp/chrony, unbound, etc... It looks like systemd.timer will continue this practice ;) I'm expecting someone at Canonical/IBM/RH will be happy to put this as the default scheduler in the next distro release, marking it as a "significant improvement".

luckycharms810 4y ago

While I agree Systemd timers aren't as ergonomic to set up - there are some benefits that I would basically never give up at this point. * Running the service on command ( this is the best way to troubleshoot issues with your slightly different environments / cron's version of shell. I've spent many minutes over my career - setting the crontab one minute and the future and waiting for it to run / fail ) * Easily inspecting when the next run of the service is. ( list-timers ) * Straightforward access to the logs ( Always journalctl ) * Specifying environment variables easily * OnFailure

jamespwilliams 4y ago
* Built in locking (so you don't need to worry about two instances of your cron running at the same time) * Built in functionality for telling when the cron last ran, and whether it was successful or not (so you can do alerting) * Ability to specify human-readable schedules * Built-in feature for randomising cron start time to avoid stampeding
- klodolph 4y ago
  The built-in locking is IMO a big deal. If you have a script that you run every 24 hours, what happens when it takes 25 hours to complete? (My experience is that this happens only years later, and the people who wrote the cronjob are gone.)
mike_hearn 4y ago
Speaking on OnFailure, one of the unfortunate aspects of systemd timers (which are otherwise quite nice) is you need to do extra work to get proper emails when something fails. Here's how I do this: Define email-unit-status@.service [Unit] Description=Email status for %i to root After=network.target [Service] Type=oneshot ExecStart=email-unit-status %i Define email-unit-status (a script) #!/usr/bin/env bash set -eu dest="admin@whatever.com" userflag= if [[ $HOME == /home/* ]]; then userflag=--user fi html=$(SYSTEMD_COLORS=1 systemctl $userflag status --full "$1" | ansi2html -w -c) /usr/sbin/sendmail -t <<ERRMAIL To: $dest From: systemd <${USER}@${HOSTNAME}> Subject: SystemD unit failure alert: $1 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset=UTF-8 Mime-Version: 1.0 $html ERRMAIL Then you can add to a service: OnFailure=email-unit-status@%n You will need to install the ansi2html tool. This stuff should come with systemd really.

karlicoss 4y ago

Some time ago I wanted the best bits from both worlds: - from cron: specifying all jobs in one file instead of scattering it across dosens of unit files. In 90% of cases I just want a regular schedule and the command, that's it - from systemd: mainly monitoring and logging. But also flexible timers, timeouts, resource management, dependencies -- for the remaining 10% of jobs which are a little more complicated So I implemented a DSL which basically translates a python spec into systemd units -- that way I don't have to remember systemd syntax and manually manage the unit files. At the same time I benefit from the simplicity of having everything in one place. An extra bonus is that the 'spec' is just normal python code - you can define variables/functions/loops to avoid copy pasting - you can use mypy to lint it before applying the changes - I have multiple computers that share some jobs, so I simply have a 'common.py' file which I import from `computer1.py` and `computer2.py` -- the whole thing is very flexible. You can read more about it here: - https://beepb00p.xyz/scheduler.html https://beepb00p.xyz/scheduler.html - https://github.com/karlicoss/dron#what-does-it-do https://github.com/karlicoss/dron#what-does-it-do I've been using this tool for several year now, with hundreds of different jobs across 3 computers, and it's been working perfectly for me. One of the best quality of life improvements I've done for my personal infrastructure.

smm11 4y ago

dale_glass 4y ago
I never quite understood that criticism, since systemd is extremely unapologetically Linux centric. It uses all the cool features of the kernel. It's configured with text files, and has an override system that works great with the Linux filesystem layout and package manager -- much better than SysV init, by the way. And it handles a lot of little annoyances that have long been a thorn in an admin's/user's side on Linux.
- ThatGeoGuy 4y ago
  Some parts are extremely Linux-centric. I'd argue the better parts of systemd (it's not all bad but there's a lot of low-hanging fruit for all of us to gripe and bicker about) are the imaginings that came from launchd. That for sure was more UNIX centric than "linux" in particular. You're right that the criticism "just become windows" seems weird - if anything else one should just say "get a mac" since that's where a lot of the launchd ideas originated.
  - dale_glass 4y ago
    I mean, systemd makes heavy use of Linux-only APIs. For instance it's very reliant on cgroups, a Linux-only feature. The main project rejects even trying to be portable. This ensures there's no such thing as accounting for that some feature might not work on FreeBSD, because the project just clearly states that it won't be a thing on *BSD.
jeroenhd 4y ago
God, I wish Linux would copy more Windows features. Service management before systemd was a hell of intermingled shell scripts (that often specified sh but only ran on bash) and side effects everywhere. Cron is a very stable tool but it should've been replaced when the first GUI ran on Linux. I don't understand this idolisation of 70s mainframes that "hardcore" Linux users all seem to fight for. Systemd features can all be turned off if you want them to, but every day more and more alternatives go into maintenance mode because nobody uses them anymore. Inetdwas great when it was invented but we've moved past that point more than ten years ago. When I'm tinkering, I love the great hacks I can apply by modifying system shell scripts, but I mostly just want my computers to work for me. The old ways of randomly placed dot files, custom service scripts (and formats) and modifying scripts that I shouldn't need to ever touch anyway because they conflict with another cobbled together script have caused me more headaches than systemd ever has. I wish system's docs were easier to find, but even the obscure man page names are better than comments in bash scripts somewhere in /etc/init.d.

tb_technical 4y ago

Why? Crob is simple, well understood, and works well. Why in god's name do you want to reinvent the wheel?

hulitu 4y ago
Because is not round enough. This is a trend in SW: facelift every couple of years.
yawaramin 4y ago
How does it work if I want to ensure that a certain volume must be mounted before a job runs?
- tb_technical 4y ago
  Add the check at the start of the script?
  - yawaramin 4y ago
    What check exactly? What's the command?
    - tb_technical 4y ago
      Try this, replace "/foo/bar" with the path to your mount point, and the echos with additional desired behaviour. (I'm assuming you're writing a bash script on a Linux system) if grep -qs '/foo/bar' /proc/mounts; then echo "/foo/bar mounted" else echo "/foo/bar not mounted" return 1 || exit 1 fi Put these commands below the shebang but before the start of the script. I hope this helps you! Edit: I added a crapload of newlines to better show the indentation and newlines required for the script to work. Sorry it's ugly

exabrial 4y ago

> Job output will automatically be written to systemd-journald This is a bad thing, not something I’d boast about. I actually really enjoy using systemd. Being able to start a process with complete isolation without heavyweight docker downloading mystery meat off the internet is a huge boon. However, one thing systemd is logging. Jounalctl sucks. Grep, cat, etc, work infinitesimally better.

kaba0 4y ago
You can redirect all your logs to traditional string-based ones if you want though.
- exabrial 4y ago
  Precisely. That's exactly what we end up doing
yawaramin 4y ago
'Infinitesimally' means 'by a negligible amount'. Which is (accidentally) accurate. There's nothing preventing you from using grep, cat, etc. with the output of journalctl. It's just a tool in the pipeline.

deleted 4y ago

[deleted]