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

301–309 of 309 posts

Re: Love systemd timers

#301

Post by thomashabets2 »

sophacles wrote: post #296
thomashabets2 wrote: post #291

Earlier quoted context omitted.

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.

Ok, now that you're just commenting cope and ad hominem I think we're done here.

Re: Love systemd timers

#302

Post by thomashabets2 »

mike_hock wrote: post #298
thomashabets2 wrote: post #292

Earlier quoted context omitted.

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

> It's a workaround for a design flaw.

That's what I'm saying though; how is it a design flaw? It's arguably a flaw in the default configuration. That's certainly fixable without changing the design at all.

> Trigger on demand would of course solve that.

Is it a design flaw that you can't trigger the job as a test? No, that's just a missing feature.

Re: Love systemd timers

#303

Post by simoncion »

harshreality wrote: post #299
simoncion wrote: post #286

Earlier quoted context omitted.

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

> It's not going to look as clean. Is that what you mean?

Nope. I don't give a shit how "clean" something looks, [0] I just care how difficult it is to learn and either retain or remind yourself of the syntax when you need to do something complex with it. In that regard, [1] systemd-crond's scheduler syntax is at least as complicated as that of most crons'.

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

So, you have to learn a tool-specific format. Just like you do for crontab. I've read both man pages, and I'm 100% unconvinced that systemd-crond's scheduler syntax is actually simpler. I do agree that it can express specific schedules that one cannot in the syntaxes used by most cron implementations.

> Very little follows from cron's format. You have to learn which fields are which for your particular implementation:

Sure. And I expect that exactly nothing other than systemd-crond uses its weirdo syntax. And -as I mentioned in the comment you're replying to-

  Nah. It's just there are a very large number of cron implementations. If The Systemd Project were actually a thing that people could make an independent reimplementation of, we'd see at least as much inconsistency in 'systemd-cron' scheduling syntax as people extended it in their reimplementations to meet their needs.
> 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...

On this I agree with you. Changing the rules for the Day Of The Week column (but only when it's used in combination with the day of the month column) is catastrophically idiotic. The only time I've ever had need to use the DoW column was to schedule something to run weekly... so I've been blissfully unaware of how incredibly idiotic that behavior is.

[0] If anything, I've noticed a strong inverse correlation between how "clean" a syntax is regarded to be and how easy it is to both do complicated things with it, and come back to those complicated pieces of work six+ months later and be able to understand what the hell you did.

[1] With the notable exception of cron's DoW column.... read on for further discussion.

Re: Love systemd timers

#304

Post by [deleted] »

thomashabets2 wrote: post #301
sophacles wrote: post #296

Earlier quoted context omitted.

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.

Ok, now that you're just commenting cope and ad hominem I think we're done here.

[deleted]

Re: Love systemd timers

#305

Post by WhyNotHugo »

gchamonlive wrote: post #23

Moved from cronie to systemd timers because they are resilient to system startup times. My backup strategy is to create a borg archive entry every day at a fixed time. With cronie the system needs to be running at the scheduled time, but systemd timer tolerates this and runs the service as soons as the system is available. Btw this is my repo for the backup automation: https://github.com/gchamon/borg-automated-backup…

Snooze offers similar resilience to the system being offline: https://github.com/leahneukirchen/snooze

I find it very easy to reason about: a single process maps to a single recurring task.

It can track last execution into a file, yielding durable schedules when the host is offline.

Re: Love systemd timers

#306

Post by harshreality »

simoncion wrote: post #303
harshreality wrote: post #299

Earlier quoted context omitted.

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

> It's not going to look as clean. Is that what you mean? Nope. I don't give a shit how "clean" something looks , [0] I just care how difficult it is to learn and either retain or remind yourself of the syntax when you need to do something complex with it. In that regard, [1] systemd-crond's scheduler syntax is at least as complicated as that of most crons'. > You don't have to count fields to figure out whether you'…

I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. Mine is: why not migrate since they're both "weirdo" syntax, and systemd's is at least based on ISO8601 and has integration with other systemd features.

Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fields, the syntax becomes ambiguous... not to a parser, but to whoever's reading and writing the lines, unless they already know the exact cron variant in use. Google, the one large cloud provider that seems to have stuck with basic cron syntax without quartz-scheduler extras, even invented their own pseudo-natural-language scheduling syntax to fill in for features cron lacks, or for people who don't like cron syntax.

Systemd's is definitely novel, but as I keep repeating, it's ISO8601 + cron. An alternative would be some extension to ISO8601 interval syntax, but that looks clunky and has probably never been used outside of niche applications for data interchange, probably inside xml files; it's used in https://docs.cibseven.org/manual/2.0/reference/bpmn20/events... (syntax at https://en.wikipedia.org/wiki/ISO_8601#Durations ). I think systemd's syntax is better than that.

The direct benefits, even if cron syntax suffices: Calendar timers are integrated with systemd, with all its process-management capabilities[1]. Unifying to systemd timers also avoids duplication of functionality ("is this scheduled process managed by systemd or cron?"). Cron doesn't let you `systemctl list-timers --all`. You'd have to grep through cron logs, possibly (and ironically) using journalctl, or have those logs already in a management dashboard, and that still doesn't let you see the next time the timer would fire. Cron also doesn't let you beta-test cron lines like you can with `systemd-analyze calendar --iterations 10 "Fri *~8..14/1"`

There's even a systemd-cron translator/generator that's in the official debian/ubuntu repos, and in Arch's AUR of course, which avoids the need for system cron but allows you to retain existing crontabs by importing them as systemd timers. They won't be quite as well integrated because it uses defaults for task names and other parameters, but the crontabs get run... without cron.

[1] https://unix.stackexchange.com/a/281203

Re: Love systemd timers

#307

Post by simoncion »

harshreality wrote: post #306
simoncion wrote: post #303

Earlier quoted context omitted.

> It's not going to look as clean. Is that what you mean? Nope. I don't give a shit how "clean" something looks , [0] I just care how difficult it is to learn and either retain or remind yourself of the syntax when you need to do something complex with it. In that regard, [1] systemd-crond's scheduler syntax is at least as complicated as that of most crons'. > You don't have to count fields to figure out whether you'…

I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. Mine is: why not migrate since they're both "weirdo" syntax, and systemd's is at least based on ISO8601 and has integration with other systemd features. Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fiel…

> I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax.

I'll repeat my opinion, as expressed in my first post:

  To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example:
  
    Mon,Fri *-01/2-01,03 *:30:45
  
  Who'd ever want to go back crontab format for nontrivial scheduling? [1]

  [0] 
  [1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex things are -if they're possible at all- at least as complex as they are everywhere else.

Re: Love systemd timers

#308

Post by harshreality »

simoncion wrote: post #307
harshreality wrote: post #306

Earlier quoted context omitted.

I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. Mine is: why not migrate since they're both "weirdo" syntax, and systemd's is at least based on ISO8601 and has integration with other systemd features. Nobody is all that happy with cron's limitations. That's why there are so many variants, with varying features. When a variant has more than 5 fiel…

> I take it that your position is: cron works for me, so why migrate to another system that uses its own "weirdo" syntax. I'll repeat my opinion, as expressed in my first post: To do nontrivial scheduling you'd use the entirely-obvious-and-intuitive syntax described at [0]. For example: Mon,Fri *-01/2-01,03 *:30:45 Who'd ever want to go back crontab format for nontrivial scheduling? [1] [0] [1] This question is sarca…

System cron can't implement your example, so I guess what you say is technically true... EINVAL is more obvious and intuitive than . Cron just can't do what you want.

You keep saying systemd calendar format is "at least as complicated", but it seems to me the converse is true. Simple cases are simpler to represent in systemd because fields are optional in various circumstances; complex cases, where they can be implemented in system cron at all, look equivalently complex. Removing the weekday constraint, rounding to minutes, and removing the star for year since it's optional:

    31 * 01,03 01/2 *
    01/2-01,03 *:31
What's the point of your gripes? Would you really suggest to someone, who has a systemd-based distro, to spin up systemd-cron or cronie and keep writing crontabs? Do you have some specific complaint about systemd calendar syntax that you think could be improved?

Re: Love systemd timers

#309

Post by Tepix »

mjmas wrote: post #266
Tepix wrote: post #239

Earlier quoted context omitted.

> But good luck doing that in one line in cron. Two options: 0 0 25-31 5 1 or, if your cron supports „L“: 0 0 L 5 1

Won't your first line mean every Monday in May as well as days 25 to 31 of May? At least busybox's cron implements it that way: if (line->cl_Mins[ptm->tm_min] && line->cl_Hrs[ptm->tm_hour] && (line->cl_Days[ptm->tm_mday] || line->cl_Dow[ptm->tm_wday]) && line->cl_Mons[ptm->tm_mon] ) {

Woah, really? Usually in crontab lines everything has to match. I consider this to be a bug.

But first I‘d check the behavior of other crons ;-)

Post reply on HN