Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd.timer, an Alternative to Cron

andrewpillar.com

Post reply on HN
Print view View original

31–40 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#31

Post by kaba0 »

traverseda wrote: post #3

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…

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.

Re: Systemd.timer, an Alternative to Cron

#32

Post by ilyt »

traverseda wrote: post #3

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…

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

Re: Systemd.timer, an Alternative to Cron

#33

Post by rektide »

traverseda wrote: post #25
rektide wrote: post #22

Earlier quoted context omitted.

'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…

>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…

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.

Re: Systemd.timer, an Alternative to Cron

#34

Post by ilyt »

phpisthebest wrote: post #11
traverseda wrote: post #3

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…

>>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 desir…

Right but you basically never run the service ran by timer manually, so on average it's just adding noise to equation.

Having option for separate timer is all and well (after all you might want to use it to periodically start service, for example start some sync service after midnight) but for cron-like behaviour it should really have all in one option, perhaps by just adding [Timer] block in .service or vice versa

Re: Systemd.timer, an Alternative to Cron

#35

Post by hagbarddenstore »

marbu wrote: post #9
traverseda wrote: post #3

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…

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.

You can still use cron if you want...

Re: Systemd.timer, an Alternative to Cron

#36

Post by lmm »

pikrzyszto wrote: post #15
ghostpepper wrote: post #5

Earlier quoted context omitted.

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 journalctl | grep nginx go back to man page to look for more options to search etc

"tail /var/log/nginx.log" is now "journalctl -fu nginx" or "jouranlctl -eu nginx". Not that much of a difference, it really depends what you grow up with. We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log". A nice feature is that journald gives you flags like "--boot" to see logs only emitted during a specific boot, or "--since '5m ago'" which is…

> We could argue "tail" is ugly because you never know if it's "tail /var/log/nginx.log" or "tail /var/log/nginx/nginx.log".

The difference is that you can use ls to find out, the same ls that you use when working with everything else, rather than needing to know some journald-specific thing that will only ever work for journald and will no doubt change again in another 5 years.

Re: Systemd.timer, an Alternative to Cron

#37

Post by luckycharms810 »

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

Re: Systemd.timer, an Alternative to Cron

#38

Post by kaba0 »

throwaway894345 wrote: post #30
candiddevmike wrote: post #18

Earlier quoted context omitted.

I personally find journalctl -fu $service very cathartic, because I'm almost always typing this command when $service isn't working.

I really need to alias `journalctl -fu` to something because it's always so tedious to type all that out over and over when I'm trying to debug something. Also, is there any autocomplete for systemd unit names? Typing `journalctl -fu amazon-cloudwatch-agent` over and over and over is so much more tedious--ideally it would be something closer to `jctl amaz `.

I do get autocomplete for even that with bash (on nixos). Tried to have a look at my config, but I forgot what enables that, but it is a game changer.

Re: Systemd.timer, an Alternative to Cron

#39

Post by karlicoss »

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://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.

Re: Systemd.timer, an Alternative to Cron

#40

Post by kaba0 »

a1369209993 wrote: post #24
traverseda wrote: post #6

Earlier quoted context omitted.

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.

Quoted post unavailable.

That's an ultra dumb take. It is a fking trivial binary format with an open spec, which is not particularly complicated. Is linux also EEE? Because those ELF files are quite a bit more difficult to decypher...
Post reply on HN