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

51–60 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#51

Post by gnaritas99 »

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…

No, having a special way to tail your special log file isn't a feature, tail is a general utility used system wide for this for decades; breaking this is idiotic no matter what you grew up with.

Re: Systemd.timer, an Alternative to Cron

#52

Post by eulers_secret »

sparker72678 wrote: post #7

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.

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.

Re: Systemd.timer, an Alternative to Cron

#53

Post by chasil »

bigpeopleareold wrote: post #12
sparker72678 wrote: post #7

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.

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

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.

Re: Systemd.timer, an Alternative to Cron

#54

Post by jamespwilliams »

luckycharms810 wrote: post #37

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

* 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

Re: Systemd.timer, an Alternative to Cron

#55

Post by traverseda »

kaba0 wrote: post #40
a1369209993 wrote: post #24

Earlier quoted context omitted.

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

> Is linux also EEE?

Oh yes, quite intentionally. See also "viral" licenses like the GPL.

Re: Systemd.timer, an Alternative to Cron

#56

Post by ravi-delia »

superkuh wrote: post #46
whateveracct wrote: post #2

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

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.

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?

Re: Systemd.timer, an Alternative to Cron

#57

Post by civopsec »

superkuh wrote: post #46
whateveracct wrote: post #2

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

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.

Roger that.

Did that feel cathartic?

Re: Systemd.timer, an Alternative to Cron

#58

Post by whateveracct »

superkuh wrote: post #46
whateveracct wrote: post #2

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

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.

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.

Re: Systemd.timer, an Alternative to Cron

#59

Post by Someone »

ilyt wrote: post #32
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".…

> Systemd's timers should just be [Timer] block inside the .service

systemd was inspired by launchd (http://0pointer.de/blog/projects/systemd.html), and that does that (https://developer.apple.com/library/archive/documentation/Ma...), so they must have explicitly made that choice.

Re: Systemd.timer, an Alternative to Cron

#60

Post by traverseda »

kaba0 wrote: post #31
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.

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.

Post reply on HN