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

121–130 of 155 posts

Re: Systemd.timer, an Alternative to Cron

#121

Post by kaba0 »

egberts1 wrote: post #98
cookiengineer wrote: post #80

Earlier quoted context omitted.

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

Failsafe? I'm still experiencing file corruption regularly with journald on various distros. Cannot recall corruption nor unreadability with syslog.

Then you have some corrupted hardware.

Also, syslog wasn’t capable of logging during the initial stages of boot, which is pretty important.

Re: Systemd.timer, an Alternative to Cron

#122

Post by kaba0 »

exabrial wrote: post #112

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

You can redirect all your logs to traditional string-based ones if you want though.

Re: Systemd.timer, an Alternative to Cron

#123

Post by funcDropShadow »

phpisthebest wrote: post #93
kzrdude wrote: post #75

Earlier quoted context omitted.

Why isn't the timer stuff just an optional [Timer] in a unit file? Then it would be separate (separate section), even if it's in the same file.

that would be a convention or configuration debate I prefer convention for systemd. The justification for have a separate timer file instead it being in the unit file would be making it easier for someone to quickly look at what services are running on timers vs running by targets. if timers where in the services file you would have to open each one to find out what had a timer, with a separate file you just look at…

In practice, I run `systemctl list-timers` to see all the timers that exist. That could be implemented with timers in a section of the unit file as well. But by being a separate file, you can have package that installs the unit and another that installs the timer. You can use symlinks to enable the timer and delete the symlink to remove the timer.

Re: Systemd.timer, an Alternative to Cron

#124

Post by lmm »

kaba0 wrote: post #119
lmm wrote: post #36

Earlier quoted context omitted.

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

And you can just issue “systemctl” to list every service. Do you blame excavation machines because you can’t drive them when you only know how to drive a car?

If someone switched my car for an excavation machine when the car was working fine I'd definitely complain.

Re: Systemd.timer, an Alternative to Cron

#125

Post by dale_glass »

ThatGeoGuy wrote: post #79
dale_glass wrote: post #76

Earlier quoted context omitted.

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

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…

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.

Re: Systemd.timer, an Alternative to Cron

#126

Post by marbu »

ilyt wrote: post #49
marbu wrote: post #9

Earlier quoted context omitted.

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.

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

Nice, thanks for sharing this.

Re: Systemd.timer, an Alternative to Cron

#127

Post by marbu »

pikrzyszto wrote: post #90
ilyt wrote: post #47

Earlier quoted context omitted.

I'd recommend running strace on that journalctl command, you might be surprised what happens. It's even worse if you actually store journalctl logs on disk (most distros defer to storing it in ram). I have it set to store on disk and keep at most 1GB of logs On my NAS # strace journalctl -u nginx 2>&1 |grep open |wc -l 827 and curiously # strace journalctl -u baked-potato 2>&1 |grep open |wc -l 827 (no i do not have…

Why would it care about stracing? It was never too slow for me. A "bad" performance might be caused by ex. consistency checking. Benchmarks like these don't tell much - you can't reduce software performance to one number. > It's DB implementation is utter garbage. It doesn't even organize files by time or really anything useful. That sounds interesting, can you please elaborate on the internal structure of journald f…

I don't have a negative experience with journald file format. That said, the format is documented here:

https://systemd.io/JOURNAL_FILE_FORMAT/

On the other hand I agree that journald seems to call open syscall more often than I would originally expect, which can be a problem for some edge cases[1], but I don't consider this to be a real problem.

[1] https://blog.marbu.eu/posts/2022-11-20-ebpf-journald/

Re: Systemd.timer, an Alternative to Cron

#128

Post by marbu »

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

Agreed. It reminds me how I recently tried to figure out why cert rotation failed, only to realize that the cron job is sending it's error messages via email to root on a system where there is no local mail server ...

Re: Systemd.timer, an Alternative to Cron

#129

Post by ilyt »

pikrzyszto wrote: post #90
ilyt wrote: post #47

Earlier quoted context omitted.

I'd recommend running strace on that journalctl command, you might be surprised what happens. It's even worse if you actually store journalctl logs on disk (most distros defer to storing it in ram). I have it set to store on disk and keep at most 1GB of logs On my NAS # strace journalctl -u nginx 2>&1 |grep open |wc -l 827 and curiously # strace journalctl -u baked-potato 2>&1 |grep open |wc -l 827 (no i do not have…

Why would it care about stracing? It was never too slow for me. A "bad" performance might be caused by ex. consistency checking. Benchmarks like these don't tell much - you can't reduce software performance to one number. > It's DB implementation is utter garbage. It doesn't even organize files by time or really anything useful. That sounds interesting, can you please elaborate on the internal structure of journald f…

> Why would it care about stracing? It was never too slow for me. A "bad" performance might be caused by ex. consistency checking. Benchmarks like these don't tell much - you can't reduce software performance to one number.

Well, I was routinely getting multi-second wait for operations like systemctl status servicename which is not something rare, because it didn't even kept the pointer to file that has last few lines of app's logs. It's not just benchmarks

It also trashes cache with hundreds of MBs of logs instead of stuff apps running on server actually needs. An equivalent of "tail -f" can go thru hundreds of megabytes of binary logs.

Re: Systemd.timer, an Alternative to Cron

#130

Post by marbu »

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.

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.
Post reply on HN