19 ms·

https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/ Locality of behavior is important. Note how this systemd-thingy i

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
  One of my earliest experiences with systemd's binary log files was on an embedded system I had ~~chrooted~~ systemd-nspawned into, and every time I tried to get the log output it would segfault (some issue with qemu-static probably). Very frustrating experience. Really feels like "Embrace, extend, extinguish" but the thing they're extinguishing is unix-as-a-programming-environemnt.
  - sliken 4y ago
    Or a Redhat plan to generate more consulting/support income. Ever wonder why Oracle products were so hard to install/maintain?
    - egberts1 4y ago
      It's the IBM way. Everything be in 4-digit or 5-digit error code. Need to RTFM for such codes. Or worse, StackOverflow them.
    - yawaramin 4y ago
      Yes, a for-profit corporation has the nefarious plan to... checks notes ...try to earn more revenues. We certainly can't stand for that!
      - sliken 4y ago
        Heh, well making your product worse for more revenue seems pretty warped, and increases the risk of lost market share. Even more warped is having 2 of your engineers join the Debian technical committee and use the bylaws to force a vote before anyone figures out exactly what SystemD is.
        deleted 4y ago
        [deleted]
        yawaramin 4y ago
        Were they coerced to vote for it? Why did they vote for it if they didn't know what it is? Honestly it's hilarious how systemd haters see conspiracies everywhere.
userbinator 4y ago
Some people just seem to love reinventing square wheels. I suspect this "spiral of complexity" is largely the result of people trying to justify their salary, because it lends itself to generating a lot of otherwise unnecessary work.
marbu 4y ago
This split between service file (what is going to happen exactly) and a timer file (when it's going to happen) is ok for complex use cases, but it really feels a bit silly when a single cron line would do the trick instead.
- hagbarddenstore 4y ago
  You can still use cron if you want...
- ilyt 4y ago
  there is cmdline shortcut for one-off ones at the very least systemd-run --user --unit=timer-name --on-active=60 /exec/path will run it in 60 seconds
  - marbu 4y ago
    Nice, thanks for sharing this.
- marbu 4y ago
  Also the split allows easier debugging: one can define and run the service, check that it works, and then define a timer and test that separately.
phpisthebest 4y ago
>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desirable" it is they disagree that is more desirable than having a logical separation of concerns... To me I prefer greater separation of concern than locality
- traverseda 4y ago
  I think that's probably a trade off that large enterprises often make. It tends to work well for very large teams, and especially if you're trying to make your tech team fungible. Still, there's such a thing as taking it too far. I think there's a middle ground. Sure, a single crontab makes it hard for packages to schedule things and makes it hard to assign ownership to individual packages/people/whatever. I can recognize that, and how it would be a problem for a large enterprise or even just for software developers who want to bundle some kind of cronjob with their package. What you could do instead of a crontab is have one folder with a bunch of services/timers in it, where each file represents a single service that needs to be run. It would mean that you can still understand all of what's going on timer wise by looking carefully at one source, but you can still assign different services/timers to different people/packages/organizational-units/whatever. Splitting each individual cronjobs into 2 different files is just crazy from where I am. Like you already have a bunch of different service types, at least give us the option to use a "periodic-oneshot" service type instead of this craziness. There's no need to have different packages/people responsible for a service and its timer, and if there is some edge case where it is you can still have ssperate timer services just they can live in a separate periodic-oneshot service file and use the original service as a dependency. There's separation of concerns and then there's this. Take any principle too far and you get some craziness, and systemd has most of the infrastructure needed to solve this in a much more elegant way. Like at some point it has to just be bad design and not just different priorities, right?
  - phpisthebest 4y ago
bravetraveler 4y ago
I think timers handle this fine -- one part sets up the work (service), the other sets up the scheduling of the job (timer) Speaking of behavior, let's look at cron. Consider every time you've written one. There's a good chance that it failed for some time because you forgot PATH is make believe there Or logging. How many times has rotation been rewritten (and broken)? Without digging through logs that may or may not exist, can you tell me when it last ran successfully? I can with timers, 'for free'
- traverseda 4y ago
  I'm definitely not saying someone couldn't write a better cron, or that it doesn't have warts. Still, put 1/10th of the budget towards cron that went towards this and I think you'd get something a lot more usable.
lazide 4y ago
Well, except for /etc/crontab, /etc/corn.daily|weekly|whatever, /var/spool/crontabs, etc.
- ciupicri 4y ago
  /etc/cron.{hourly,daily,weekly,monthly} are just some convenience shortcuts. No one is forcing you to use them.
  - lazide 4y ago
    When a bunch of important system functionality is done using them, I’m required to know they exist. /etc/crontab is no different. It’s not that much different than systemd in that sense. Especially since the /etc/cron.whatever special rules like files with dots in them get ignored (ugh)
    - jerf 4y ago
      Another fun one I've gotten bitten by a lot is that the /etc/cron.* directories are run sequentially, so if someone who doesn't know this put some long running process in it, ideally with a name that sorts first, it blocks everything else in that directory. (I personally know this, obviously, since I'm saying it now, but I've been bitten by the other people who do not realize this and do not think about how putting a process that may run for three hours at the beginning of cron.hourly means that the other processes may not run for that long.)
rektide 4y ago
'Make everything simple as it can be but no simpler'. To me your ask violates this. Timers augment the variety of existing service types, so your idea just doesnt work straight up, unless we severely limit the flexibility of what timers can be via the 'periodic' type. Or we make 'periodic-oneshot' 'periodic-serice' et cetera, which feels absurd. Perhaps we could leave Service= alone & just shoehorn each systemd.timer option into system.service. But then we need some way to view the timer statuses & logs, which we can easily review and handle by having a separate unit. 'list-timers' is ok & might still work but we cant filter and log as well if everything is jammed together. We also cant just disable a timer temporarily, & go manage the service manually for a bit, if somethings going sideways & we need to step in; the two are now one in your world. And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). We eliniate a lot of creative ability by glomming stuff together. I dont like this idea. I think it's a misservice to jam everything together. Systemd has similar patterns of representing different pars in different places that I think has served it well. It's an even more trivial case that is more supportable by this idea you've floated, but there is a systemd.mount and systemd.automoumt. It's just good, as an operator, having clear boundaries between these units, and has always made it clearer to me what aspect Im operating on, and enabled healthier patterns of system growth.
- traverseda 4y ago
  >And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). Well, that's where you can write a regular timer or just add a dependency to your timer-service. But also you're sort of getting to the territory of inventing your own scripting language on top of systemd at that point, if your needs are that complex just write a script.
  - rektide 4y ago
    This feels quite dismissive to me. I dont see the appeal of any of these three options, given how well systemd.timers solve all of this today & how nicely they compose. The whole point is to not need to keep running into a bunch of artisinal handcrafted did-it-myself shell scripts every time come to a system. Being able to compose timers that trigger units enables this nicely with a lot of flexibility. Managing them separately is powerful & makes sense.
kaba0 4y ago
Starting a service is way different than the service itself, what if I want it to be started when a request hits a given port? Also, the service files themselves are usually packaged up and are immutable, and every user will want different behavior on when it is started. To me it sounds like proper architecture and your solution would be needless close coupling.
- traverseda 4y ago
  Sure, then let me put a command in my files instead of requiring a separate service. >what if I want it to be started when a request hits a given port? I really don't think you should be turning your init system into a general programming environment that can do that.
  - bravetraveler 4y ago
    > I really don't think you should be turning your init system into a general programming environment that can do that. We have :) https://www.freedesktop.org/software/systemd/man/systemd.socket.html https://www.freedesktop.org/software/systemd/man/systemd.soc... No need for multiple anything, the units can be parameterized -- user@my.service, for example
    - traverseda 4y ago
      Oh I know it's possible, I just don't think you should be doing that in an init system.
      - bravetraveler 4y ago
        Understood, fair enough. I'm not too bothered by it, it's been useful here and there
  - kaba0 4y ago
    Socket activation is declarative. My last point is the dynamic one, but that is just calling out to systemd. The point is, all three can share the same service description.
ilyt 4y ago
Then again original cron is also kinda shit. It gets the "one file to define the job" right but that's the only thing that it gets right. There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert. There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay". You can get that info from logs but you can't get the content of error message of the app from those logs... Environmental options history is.... interesting, better to just make script that sets everything up beforehand instead of even trying to do it via cron. From ops perspective of managing multiple servers its utter garbage. From single user perspective it kinda works but is annoying Systemd's timers should just be [Timer] block inside the .service
- Someone 4y ago
  > Systemd's timers should just be [Timer] block inside the .service systemd was inspired by launchd (http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html), and that does that (https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html#//apple_ref/doc/uid/10000172i-CH1-SW2 https://developer.apple.com/library/archive/documentation/Ma...), so they must have explicitly made that choice.
  - __turbobrew__ 4y ago
    The wrong choice in my opinion
- Enginerrrd 4y ago
  The thing about cron though is this: I learned how to run crontab easily once and I've retained the knowledge of how to use it ever since. It's a piece of cake, I don't think I've ever had a cron job fail on me except for the path issue but I've always caught that on creation since I test them right after I make it. With systemd timers, I have to look up how to write a unitfile every. single. time. and it's not a trivial 30-second lookup like every other command, it's a 5-10 minute read through every time. And even then there's weird variations on the timer unit files I don't quite understand, and most of the time it takes more than one try to get right. It fails in some bizarre ways on certain tasks due to internal systemd inconsistencies. (Like using different escape characters in different contexts, wtf?!) And I can't remember how it's set-up so I have to look it up again when I want to administer it or change something and on the whole it's just a huge PITA. At this point, I've used systemd timers several times MORE than I have cron and I still have no idea how to write a systemd timer unit file without looking it up, and I'd have to start from scratch to write a new one. About the only positive is that when it fails systemd reports it decently so I can follow up on it, but man, it's not worth it. I've spent a lot more time dicking with the unit files than I have debugging failed cron jobs.
dralley 4y ago
> 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. systemctl list-timers is vastly more informative in a practical sense than just looking at the crontab. It just straight up tells you exactly when it ran last, how long ago that was, when it will run next, and how much time is left until that happens.
- alyandon 4y ago
  More importantly, you don't have to worry about fat-fingering an entry in your crontab and having everything from that point onward silently fail.
cookiengineer 4y ago
Counter argument: Try implementing support for Alpine, Debian and other distros whilst using a cronjob. It's impossible. All that opinionated /etc/crontab and /etc/cron.daily shit can go to hell for all I care. Every opinionated distro uses whatever kind of file format that the next best sh guru came up with, which id also prone for exploitation btw. With systemd there's a failsafe way for maintainers to offer a cross-distro way to integrate their software. And that's what systemd is about: automation of integration through convention.
- traverseda 4y ago
  I'm not sure what you mean? Alpine doesn't have systemd at all.
- egberts1 4y ago
  Failsafe? I'm still experiencing file corruption regularly with journald on various distros. Cannot recall corruption nor unreadability with syslog.
  - kaba0 4y ago
    Then you have some corrupted hardware. Also, syslog wasn’t capable of logging during the initial stages of boot, which is pretty important.
    - egberts1 4y ago
      That's what dmesg is for.
    - egberts1 4y ago
      Then there aught to be some kind of fsck (file checking) for journal files. To forever complain until user intervention is downright silly. Five separate but disparate hardware does not make for a probable hardware error.
outworlder 4y ago
I guess preferences will mostly depend on how the system is being used. If this is your desktop machine sure, do crontab -e and add a line. If it is a system sitting in a colo or cloud provider, it's likely that it's been configured through automation anyways so "locality" doesn't matter. Your scripts know where stuff is located.
- traverseda 4y ago
  My scripts an also do things like assemble a crontab, since it doesn't matter.

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
One of my earliest experiences with systemd's binary log files was on an embedded system I had ~~chrooted~~ systemd-nspawned into, and every time I tried to get the log output it would segfault (some issue with qemu-static probably). Very frustrating experience. Really feels like "Embrace, extend, extinguish" but the thing they're extinguishing is unix-as-a-programming-environemnt.
- sliken 4y ago
  Or a Redhat plan to generate more consulting/support income. Ever wonder why Oracle products were so hard to install/maintain?
  - egberts1 4y ago
    It's the IBM way. Everything be in 4-digit or 5-digit error code. Need to RTFM for such codes. Or worse, StackOverflow them.
  - yawaramin 4y ago
    Yes, a for-profit corporation has the nefarious plan to... checks notes ...try to earn more revenues. We certainly can't stand for that!
    - sliken 4y ago
      Heh, well making your product worse for more revenue seems pretty warped, and increases the risk of lost market share. Even more warped is having 2 of your engineers join the Debian technical committee and use the bylaws to force a vote before anyone figures out exactly what SystemD is.
      - deleted 4y ago
        [deleted]
      - yawaramin 4y ago
        Were they coerced to vote for it? Why did they vote for it if they didn't know what it is? Honestly it's hilarious how systemd haters see conspiracies everywhere.

userbinator 4y ago

Some people just seem to love reinventing square wheels. I suspect this "spiral of complexity" is largely the result of people trying to justify their salary, because it lends itself to generating a lot of otherwise unnecessary work.

marbu 4y ago

This split between service file (what is going to happen exactly) and a timer file (when it's going to happen) is ok for complex use cases, but it really feels a bit silly when a single cron line would do the trick instead.

hagbarddenstore 4y ago
You can still use cron if you want...
ilyt 4y ago
there is cmdline shortcut for one-off ones at the very least systemd-run --user --unit=timer-name --on-active=60 /exec/path will run it in 60 seconds
- marbu 4y ago
  Nice, thanks for sharing this.
marbu 4y ago
Also the split allows easier debugging: one can define and run the service, check that it works, and then define a timer and test that separately.

phpisthebest 4y ago

>>Locality of behavior is important. Even your own link talks about the Subjectivity of that opinion, and how LoB is often in conflict with DRY and SoC, both of which I support far more than LoB. In this context systemd favors Separation of Concerns, the the service is what is being run, and the timer is when is it being run... it is not that the devs do not "seem to understand why locality of behavior would be desirable" it is they disagree that is more desirable than having a logical separation of concerns... To me I prefer greater separation of concern than locality

traverseda 4y ago
I think that's probably a trade off that large enterprises often make. It tends to work well for very large teams, and especially if you're trying to make your tech team fungible. Still, there's such a thing as taking it too far. I think there's a middle ground. Sure, a single crontab makes it hard for packages to schedule things and makes it hard to assign ownership to individual packages/people/whatever. I can recognize that, and how it would be a problem for a large enterprise or even just for software developers who want to bundle some kind of cronjob with their package. What you could do instead of a crontab is have one folder with a bunch of services/timers in it, where each file represents a single service that needs to be run. It would mean that you can still understand all of what's going on timer wise by looking carefully at one source, but you can still assign different services/timers to different people/packages/organizational-units/whatever. Splitting each individual cronjobs into 2 different files is just crazy from where I am. Like you already have a bunch of different service types, at least give us the option to use a "periodic-oneshot" service type instead of this craziness. There's no need to have different packages/people responsible for a service and its timer, and if there is some edge case where it is you can still have ssperate timer services just they can live in a separate periodic-oneshot service file and use the original service as a dependency. There's separation of concerns and then there's this. Take any principle too far and you get some craziness, and systemd has most of the infrastructure needed to solve this in a much more elegant way. Like at some point it has to just be bad design and not just different priorities, right?
- phpisthebest 4y ago

bravetraveler 4y ago

I think timers handle this fine -- one part sets up the work (service), the other sets up the scheduling of the job (timer) Speaking of behavior, let's look at cron. Consider every time you've written one. There's a good chance that it failed for some time because you forgot PATH is make believe there Or logging. How many times has rotation been rewritten (and broken)? Without digging through logs that may or may not exist, can you tell me when it last ran successfully? I can with timers, 'for free'

traverseda 4y ago
I'm definitely not saying someone couldn't write a better cron, or that it doesn't have warts. Still, put 1/10th of the budget towards cron that went towards this and I think you'd get something a lot more usable.

lazide 4y ago

Well, except for /etc/crontab, /etc/corn.daily|weekly|whatever, /var/spool/crontabs, etc.

ciupicri 4y ago
/etc/cron.{hourly,daily,weekly,monthly} are just some convenience shortcuts. No one is forcing you to use them.
- lazide 4y ago
  When a bunch of important system functionality is done using them, I’m required to know they exist. /etc/crontab is no different. It’s not that much different than systemd in that sense. Especially since the /etc/cron.whatever special rules like files with dots in them get ignored (ugh)
  - jerf 4y ago
    Another fun one I've gotten bitten by a lot is that the /etc/cron.* directories are run sequentially, so if someone who doesn't know this put some long running process in it, ideally with a name that sorts first, it blocks everything else in that directory. (I personally know this, obviously, since I'm saying it now, but I've been bitten by the other people who do not realize this and do not think about how putting a process that may run for three hours at the beginning of cron.hourly means that the other processes may not run for that long.)

rektide 4y ago

'Make everything simple as it can be but no simpler'. To me your ask violates this. Timers augment the variety of existing service types, so your idea just doesnt work straight up, unless we severely limit the flexibility of what timers can be via the 'periodic' type. Or we make 'periodic-oneshot' 'periodic-serice' et cetera, which feels absurd. Perhaps we could leave Service= alone & just shoehorn each systemd.timer option into system.service. But then we need some way to view the timer statuses & logs, which we can easily review and handle by having a separate unit. 'list-timers' is ok & might still work but we cant filter and log as well if everything is jammed together. We also cant just disable a timer temporarily, & go manage the service manually for a bit, if somethings going sideways & we need to step in; the two are now one in your world. And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). We eliniate a lot of creative ability by glomming stuff together. I dont like this idea. I think it's a misservice to jam everything together. Systemd has similar patterns of representing different pars in different places that I think has served it well. It's an even more trivial case that is more supportable by this idea you've floated, but there is a systemd.mount and systemd.automoumt. It's just good, as an operator, having clear boundaries between these units, and has always made it clearer to me what aspect Im operating on, and enabled healthier patterns of system growth.

traverseda 4y ago
>And what if you want multiple timers, with different configurations between them (maybe one long running one with WakeSystem= and a shorter one without?). Well, that's where you can write a regular timer or just add a dependency to your timer-service. But also you're sort of getting to the territory of inventing your own scripting language on top of systemd at that point, if your needs are that complex just write a script.
- rektide 4y ago
  This feels quite dismissive to me. I dont see the appeal of any of these three options, given how well systemd.timers solve all of this today & how nicely they compose. The whole point is to not need to keep running into a bunch of artisinal handcrafted did-it-myself shell scripts every time come to a system. Being able to compose timers that trigger units enables this nicely with a lot of flexibility. Managing them separately is powerful & makes sense.

kaba0 4y ago

Starting a service is way different than the service itself, what if I want it to be started when a request hits a given port? Also, the service files themselves are usually packaged up and are immutable, and every user will want different behavior on when it is started. To me it sounds like proper architecture and your solution would be needless close coupling.

traverseda 4y ago
Sure, then let me put a command in my files instead of requiring a separate service. >what if I want it to be started when a request hits a given port? I really don't think you should be turning your init system into a general programming environment that can do that.
- bravetraveler 4y ago
  > I really don't think you should be turning your init system into a general programming environment that can do that. We have :) https://www.freedesktop.org/software/systemd/man/systemd.socket.html https://www.freedesktop.org/software/systemd/man/systemd.soc... No need for multiple anything, the units can be parameterized -- user@my.service, for example
  - traverseda 4y ago
    Oh I know it's possible, I just don't think you should be doing that in an init system.
    - bravetraveler 4y ago
      Understood, fair enough. I'm not too bothered by it, it's been useful here and there
- kaba0 4y ago
  Socket activation is declarative. My last point is the dynamic one, but that is just calling out to systemd. The point is, all three can share the same service description.

ilyt 4y ago

Then again original cron is also kinda shit. It gets the "one file to define the job" right but that's the only thing that it gets right. There is no holistic view on the jobs so you can't easily say "show me last jobs that failed" and shove that into alert. There is email on failure but only on failure so you can't also do simple "if this mail returns fail, mark check as failed, if it returns okay, mark it as okay". You can get that info from logs but you can't get the content of error message of the app from those logs... Environmental options history is.... interesting, better to just make script that sets everything up beforehand instead of even trying to do it via cron. From ops perspective of managing multiple servers its utter garbage. From single user perspective it kinda works but is annoying Systemd's timers should just be [Timer] block inside the .service

Someone 4y ago
> Systemd's timers should just be [Timer] block inside the .service systemd was inspired by launchd (http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html), and that does that (https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html#//apple_ref/doc/uid/10000172i-CH1-SW2 https://developer.apple.com/library/archive/documentation/Ma...), so they must have explicitly made that choice.
- __turbobrew__ 4y ago
  The wrong choice in my opinion
Enginerrrd 4y ago
The thing about cron though is this: I learned how to run crontab easily once and I've retained the knowledge of how to use it ever since. It's a piece of cake, I don't think I've ever had a cron job fail on me except for the path issue but I've always caught that on creation since I test them right after I make it. With systemd timers, I have to look up how to write a unitfile every. single. time. and it's not a trivial 30-second lookup like every other command, it's a 5-10 minute read through every time. And even then there's weird variations on the timer unit files I don't quite understand, and most of the time it takes more than one try to get right. It fails in some bizarre ways on certain tasks due to internal systemd inconsistencies. (Like using different escape characters in different contexts, wtf?!) And I can't remember how it's set-up so I have to look it up again when I want to administer it or change something and on the whole it's just a huge PITA. At this point, I've used systemd timers several times MORE than I have cron and I still have no idea how to write a systemd timer unit file without looking it up, and I'd have to start from scratch to write a new one. About the only positive is that when it fails systemd reports it decently so I can follow up on it, but man, it's not worth it. I've spent a lot more time dicking with the unit files than I have debugging failed cron jobs.

dralley 4y ago

> 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. systemctl list-timers is vastly more informative in a practical sense than just looking at the crontab. It just straight up tells you exactly when it ran last, how long ago that was, when it will run next, and how much time is left until that happens.

alyandon 4y ago
More importantly, you don't have to worry about fat-fingering an entry in your crontab and having everything from that point onward silently fail.

cookiengineer 4y ago

Counter argument: Try implementing support for Alpine, Debian and other distros whilst using a cronjob. It's impossible. All that opinionated /etc/crontab and /etc/cron.daily shit can go to hell for all I care. Every opinionated distro uses whatever kind of file format that the next best sh guru came up with, which id also prone for exploitation btw. With systemd there's a failsafe way for maintainers to offer a cross-distro way to integrate their software. And that's what systemd is about: automation of integration through convention.

traverseda 4y ago
I'm not sure what you mean? Alpine doesn't have systemd at all.
egberts1 4y ago
Failsafe? I'm still experiencing file corruption regularly with journald on various distros. Cannot recall corruption nor unreadability with syslog.
- kaba0 4y ago
  Then you have some corrupted hardware. Also, syslog wasn’t capable of logging during the initial stages of boot, which is pretty important.
  - egberts1 4y ago
    That's what dmesg is for.
  - egberts1 4y ago
    Then there aught to be some kind of fsck (file checking) for journal files. To forever complain until user intervention is downright silly. Five separate but disparate hardware does not make for a probable hardware error.

outworlder 4y ago

I guess preferences will mostly depend on how the system is being used. If this is your desktop machine sure, do crontab -e and add a line. If it is a system sitting in a colo or cloud provider, it's likely that it's been configured through automation anyways so "locality" doesn't matter. Your scripts know where stuff is located.

traverseda 4y ago
My scripts an also do things like assemble a crontab, since it doesn't matter.