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

Love systemd timers

blog.tjll.net

Post reply on HN
Print view View original

291–300 of 309 posts

Re: Love systemd timers

#291

Post by thomashabets2 »

sophacles wrote: post #273
thomashabets2 wrote: post #250

Earlier quoted context omitted.

I am not agreeing with egorfine. Indeed, why not improve what we can improve? > cron did a job, but had shortcomings. Systemd addresses many of those shortcomings Right, but what are those "many" shortcomings? The article lists four, and fully half of them seem to be nonsense, per my comment. (time spec syntax appears to be equally complex in systemd timers, and I have no idea what they mean about PATH, as it seems e…

Well theres a few more: * coalescing jobs with control over the granularity of it. That means you can say "i want this job run on at 14:30:02 exactly" and I want these jobs run at 19:21 or so, 19:22 or so: and 19:23 and set your resoultion to 10m and they'll all run at once. Great on laptops and other scenarios where you want to reduce power draw. * System wakeup - you can wake a system from sleep various sleep modes…

I agree that's a good list. You did a better job than the article.

As for pulse audio: no, it has absolutely nothing to do with that. That's just being condescending and smug. I've never had a lithium battery fire, so that must mean manufacturing defects never cause them?

Re: Love systemd timers

#292

Post by thomashabets2 »

mike_hock wrote: post #279
thomashabets2 wrote: post #253

Earlier quoted context omitted.

> $PATH is one thing when cron runs and another when you try out the command yourself. Why would that be different with systemd timers? If my ~/.bashrc adds /opt/foo/bin, that's also not part of the systemd timer's PATH, right? But I guess you're saying the ability to trigger the systemd timer off-schedule is the difference? Yeah, it's annoying with cron to have to temporarily set the trigger two minutes into the fut…

> Why would that be different with systemd timers? Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it. > my main gripe with systemd and other Lennartware is the extremely low implementation quality It doesn't stack up that poorly against other projects but it's unacceptably low for a core system component.

> Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it.

It's a better workflow than the one I mentioned for cron, yes, but it's nothing inherent. I would not call the difference one of being "predictable", though.

The article and thread is full of complaints about cron that are either just missing features that could be added (like this one, trigger on demand), exactly the same ("the time spec is too complex"), or just plain "no you can already do that with cron".

It wasn't until this comment (https://news.ycombinator.com/item?id=48385824) that I saw viable reasons why one would need to start from scratch.

Except, of course, that "green field is more fun than improving things".

> I don't want to hardcode $PATH in the crontab just so I can test the cronjob

How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable.

> [Lennartware] doesn't stack up that poorly against other projects but it's unacceptably low for a core system component.

Well put.

Re: Love systemd timers

#293

Post by gchamonlive »

zbentley wrote: post #195
gchamonlive wrote: post #93

Earlier quoted context omitted.

Just to be clear, this isn't default systemd timer behaviour, you need to opt in by setting Persistent=true. If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool because at that scale you'd surely need better observability

> If you have hundreds of jobs like this you need a proper queue and neither cronie nor systemd is the right tool Eh sometimes, but you can get pretty far with one of two approaches: 1. Careful use of Requires= and Wants= to group your scripts into chains of jobs, which achieves fixed parallel (though at 100s of jobs, I hope you're generating those unit files with a tool like Puppet or https://github.com/karlicoss/dr…

1. This is spread across 500 files, maintainability goes out the window

2. If this for some reason fails, misconfiguration or unexpected shutdown, you could have a failure that's hard to track or debug

These are fine with a few services chained together, but this requires a shallow depth of dendencies. To have these theoretical hundreds of jobs chained together like this isn't practical or safe.

Re: Love systemd timers

#294

Post by thomashabets2 »

thayne wrote: post #285
thomashabets2 wrote: post #255

Earlier quoted context omitted.

> - the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root. What do you mean by "you would expect", that doesn't also apply to systemd timers? /opt/foo/bin is not in the path. Would you expect that? And if this is an objective problem, can we just change the cron default PATH? > - on some distributions (for example Arch Linux) the man page doesn't even say what the defau…

> What do you mean by "you would expect" I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin. I don't really expect /opt/foo/bin to be there, but if you want to have it available by default everywhere then you can just add it to systemd once, rather than having to remember to add it to crontab as well. > Or on the line, right? Oh you're right…

> I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.

So changing the default PATH for cron requires a green field rewrite? You would expect /usr/local/bin. cron doesn't include it. It seems like a disagreement on default settings. I would agree with you about what the default should be, but I don't understand how this has anything to do with cron either as code or architecture.

This seems a bit like /sbin being missing in the default PATH for the root user's regular shell being a reason to rewrite bash to systemd shell.

Re: Love systemd timers

#295

Post by thayne »

thomashabets2 wrote: post #294
thayne wrote: post #285

Earlier quoted context omitted.

> What do you mean by "you would expect" I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin. I don't really expect /opt/foo/bin to be there, but if you want to have it available by default everywhere then you can just add it to systemd once, rather than having to remember to add it to crontab as well. > Or on the line, right? Oh you're right…

> I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin. So changing the default PATH for cron requires a green field rewrite? You would expect /usr/local/bin. cron doesn't include it. It seems like a disagreement on default settings. I would agree with you about what the default should be, but I don't understand how this has anything to do wit…

> So changing the default PATH for cron requires a green field rewrite?

I never claimed that.

It's just one of many reasons why I think systemd timers are easier to use.

Re: Love systemd timers

#296

Post by sophacles »

thomashabets2 wrote: post #291
sophacles wrote: post #273

Earlier quoted context omitted.

Well theres a few more: * coalescing jobs with control over the granularity of it. That means you can say "i want this job run on at 14:30:02 exactly" and I want these jobs run at 19:21 or so, 19:22 or so: and 19:23 and set your resoultion to 10m and they'll all run at once. Great on laptops and other scenarios where you want to reduce power draw. * System wakeup - you can wake a system from sleep various sleep modes…

I agree that's a good list. You did a better job than the article. As for pulse audio: no, it has absolutely nothing to do with that. That's just being condescending and smug. I've never had a lithium battery fire, so that must mean manufacturing defects never cause them?

I get it. Some software had a couple bugs at first, as does all new software. And now some whiny people who have never, don't currently, and will never provide value to the open source ecosystem have spent more years whining and complaining about the bugs than the entire piece of software was in widespread use.

Re: Love systemd timers

#298

Post by mike_hock »

thomashabets2 wrote: post #292
mike_hock wrote: post #279

Earlier quoted context omitted.

> Why would that be different with systemd timers? Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it. > my main gripe with systemd and other Lennartware is the extremely low implementation quality It doesn't stack up that poorly against other projects but it's unacceptably low for a core system component.

> Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it. It's a better workflow than the one I mentioned for cron, yes, but it's nothing inherent. I would not call the difference one of being "predictable", though. The article and thread is full of complaints about cron that are either just missing features that could be added (like this one, trigger…

> How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable.

It's a workaround for a design flaw. If you forget it you'll notice when it fails in production. There should rarely be a need to change the default path (just specify the full path if necessary), it should just be the same when you test and when it runs by itself. Trigger on demand would of course solve that.

> exactly the same ("the time spec is too complex")

Of course, the timespec complaint is bullshit. Both have manpages that will tell you immediately if you don't have it memorized.

Re: Love systemd timers

#299

Post by harshreality »

simoncion wrote: post #286
harshreality wrote: post #280

Earlier quoted context omitted.

Obviously you can do additional time & date checking in a shell wrapping the script or binary cron ultimately runs, just as you could do the time & date checking in the script or binary itself. That's far more complex. Systemd enables cleaner, simpler syntax for common cases. Instead of "59 23 * * *", simply "23:59". Instead of "0 0 * * sun[day]", simply "sun[day]". 1st of the month and don't care exactly what time?…

> Systemd enables cleaner, simpler syntax for common cases. I disagree. It's all a matter what you're accustomed to. On top of that, what's at least as important as clear syntax for simple cases is the establishing of a handful of rules that well serve both the simple and complex cases. Consistency that leads to complicated cases being made easy should not be avoided just to make the simple cases extremely welcoming…

I think you're talking about syntactic simplicity. Systemd requires three field separators (space, :, -) because that's how ISO8601 dates are written. That means not all fields will be space separated, which may be more challenging to visually parse. It's not going to look as clean. Is that what you mean?

Everything else is simpler. You don't have to count fields to figure out whether you're dealing with a day vs a month, or an hour vs minute, no matter how the fields are aligned or how long or complex they are. You can scan left and right and look for space and dash and colon to figure out where you are. The formats for time and date are distinctive and ubiquitous. You don't have to guess what you're looking at when you just see one of them in isolation.

Very little follows from cron's format. You have to learn which fields are which for your particular implementation: does it include seconds? You have to learn the bizarre interaction between day and weekday, to do something non-trivial with them. You have to carefully keep track of which field you're in because you can't determine that from neighboring syntax. The visual clutter, if you want to call it that, of systemd's iso8601-based syntax only applies if you're doing complicated rules. In the vast majority of cases it would simply be an ISO8601 timestamp with various values replaced with *'s, and at most one /.

That first impression you had is what I thought too, before diving into it for my previous replies. But no, cron logic is that day and weekday are ORed. It lets you do clever things like run a script on the 1st and 15th of every month, AND on mondays, all in one line. I don't think I've ever seen such a thing in the wild. I'd go so far as to say it's stupid, because it's likely to be misinterpreted if anyone did use it that way. All the other fields are ANDed. I would say that systemd's AND logic is better... and more consistent, which is your own acceptance criterion.

Re: Love systemd timers

#300

Post by urineaut »

interf4ce wrote: post #33
andrewstuart wrote: post #22

Even better is systemd socket activation.

This is very interesting. I'm not sure what I'd use it for yet, but I imagine it could be useful for triggering ad hoc jobs over the network. Maybe have Home Assistant make a network call to kick off a daily back up when I leave the office at the end of a work day.

A pretty nice use case I have for socket activation is for isolating containers or applications from the host network. The great thing about socket activation is that opened sockets carry over even if the application/container unshares into a different network namespace! It also works great with Podman pods with networking in the pod completely disabled and, as those are host sockets, does fully retain the connection info of peers (so logs are not just uselessly containing the gateway IP, depending on the container network config)
Post reply on HN