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

191–200 of 309 posts

Re: Love systemd timers

#191

Post by eichin »

the_real_cher wrote: post #56
lanycrost wrote: post #37

systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl

This is such a modern view. People used to HATE systemd when it first came out, but I always liked it and knew people would eventually come around and its nice to see they finally did!

Arguably they (we :-) were right at the time. Around Ubuntu 16.04, the journal was Hot Garbage - to keep a production system working (as in, "didn't randomly stop logging, didn't regularly corrupt logs, didn't uncontrollably fill the disk because none of the limit options actually worked") we eventually backported about 30 fixes from newer versions - by 22.04 or so it was "fit for purpose" out of the box, but earlier than that it earned every bit of hatred it got.

Re: Love systemd timers

#192

Post by TacticalCoder »

egorfine wrote: post #111

We have used cron perfectly fine for decades and it served us well within its very clear limitations. But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

> But now obviously we were so blind and wrong all this time and the only true solution is of course systemd.

Oh nooooo... I've been so wrong. Seen the direction most Linux distro took I decided to move to VMs (VMs which runs systemd-less systems), OCI containers (where by definition PID 1 is not systemd) and now an hypervisor to run systemd Linux VM but I'm now into... An hypervisor that is precisely not Linux (so no systemd at all).

I sinned. So now maybe it's time to buy Microsoft stocks, praise Windows [ini] config files, and venere the Linux PID 1 god with its tentacles meddling with every part of the Linux system.

Or not.

Re: Love systemd timers

#193

Post by mschuster91 »

egorfine wrote: post #175
mschuster91 wrote: post #154

Earlier quoted context omitted.

> But now obviously we were so blind and wrong all this time and the only true solution is of course systemd. Come on, dude. That's unnecessarily polemic. cron et al have served us for decades, yes. But that doesn't mean that cron is the solution that needs to accompany us until the heat death of the universe or year 2038, whatever comes first. I agree, the systemd folks haven't exactly been the best when it comes to…

> that doesn't mean that cron is the solution that needs to accompany us until the heat Yeah I agree. > systemd folks haven't exactly been the best when it comes to PR It's deeper than that. Systemd folks are enemies of Linux. First, it's "fuck your opinion, do as we say" attitude which makes me want to throw away everything that comes from that poisonous well. Second, it's the embrace and extinguish strategy employe…

> First, it's "fuck your opinion, do as we say" attitude which makes me want to throw away everything that comes from that poisonous well.

On the other hand, it is a consistently heard argument when debating why the year of the Linux adoption on desktop hasn't happened yet is that there are too many standards, too many cooks. And I kinda agree with that, packaging software for multiple distributions is a hot mess, especially if you're shipping daemons. systemd is at least one worry less, it's a stable API that can be used for all purposes.

> And third, systemd author is up to no good: https://news.ycombinator.com/item?id=46784572

Again, this isn't as black-and-white as it seems on a cursory review.

From the perspective of someone who hates anti-rooting measures on phones, anything moving into the direction of trusted computing is bad.

But from the perspective of someone, say, in Russia, Iran, the US or Germany who might be a journalist or political activist? Suddenly, a way for the OS to attest if the hardware hasn't been manipulated in an evil maid scenario and that any successful attempt of exploiting an OS vulnerability at runtime can be reverted by a simple reboot becomes extremely vulnerable.

My personal opinion, we need strong and good attestation capabilities for a multitude of use cases. But we also need good laws that protect user freedoms, similar to "right to repair" laws we need "right to root" laws that ban applications from requiring unrooted phones.

Re: Love systemd timers

#194

Post by TacticalCoder »

htx80nerd wrote: post #185
simoncion wrote: post #109

You will love SystemD [0] timers until they fuck you over in an entirely inscrutable way and the SystemD maintainers don't care to either fix the problem or update the docs to warn of the shortcoming. One of our customers called in with a production down incident caused by a full disk. We got a copy of the VM and took a look. Investigation revealed that / was full because /var/log was full and that our 'logrotate' ti…

>The conversation from the core devs ran through the pattern that one gets used to seeing when one runs into SystemD bugs that are caused by extremely complex unanticipated interactions between parts of the project >SystemD contains an enormous -and ever-growing- amount of accidental complexity, and has a set of core maintainers who are generally disinterested in either documenting the places where one or more comple…

> ... imagine my surprise to learn that Systemd was causing my long standing frustration with changing my dns settings. and further surprise to learn that server admins have this same issue and many switch away from using systemd-resolved.

That's introductory course to systemd's shenanigans. People are going to tell you that you're not doing it properly, that there's of course this setting (unless that other setting takes precedence etc.), yada, yada, yada.

If I really have to suffer systemd the first thing I do is manually edit /etc/resolv.conf and then chattr +i /etc/resolv.conf.

And of course remove/purge systemd-resolved.

Not only is it "always the DNS" but then things turn from bad to worse when "it's the DNS, but with systemd".

Removing systemd-resolved is the first step. The second one is moving to an OS or a Linux distro that doesn't have systemd at all.

Re: Love systemd timers

#195

Post by zbentley »

gchamonlive wrote: post #93
happysadpanda2 wrote: post #87

Earlier quoted context omitted.

I interpreted it more like "I have these 500 different cronjobs all spread out across $unit_of_time. If the system is down for longer than $unit_of_time and then comes back, does all 500 jobs start running instantly (since they missed their previous deadline)?"

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/dron or something and not doing this by hand).

2. Even better, just use a lockfile. `ExecStart="flock -F $TMPDIR/mylock "` is pretty hard to beat. Use -F so as not to confuse KillMode and resource accounting and you're golden. Just don't use flock(1) timeouts; let systemd handle that. Heck, if you have that many cron jobs, you should be doing this even if you don't use systemd; otherwise job latency changes can cause reboot-style thundering herds out of the blue.

If you need semaphore behavior and still don't want a real job queue, waitlock (https://github.com/bigattichouse/waitlock) and many other CLIs have you covered.

Re: Love systemd timers

#197

Post by zaik »

Cyph0n wrote: post #28
drunner wrote: post #21

Earlier quoted context omitted.

Have you been defining them directly in your flake.nix file? I too am on nixos but I keep all my configurations in their native format and symlink them with nix, that way I can take and reuse that config on a non nixos system easily. The problem I have found is that nixos doesn't seem to pickup and run systemd timers and services placed into the ~/.config/systems/user folder and additionally things like WantedBy=defa…

I define all units in Nix because: a) It is way nicer and you get decent validation at build time b) A LLM can port units over if the need arises; it’s a very light abstraction around systemd syntax c) I personally don’t see how I would ever move to another distro :)

b) Or you could take the compiled units from /etc/systemd and copy them wherever

Re: Love systemd timers

#198

Post by zbentley »

Eduard wrote: post #178
louiskottmann wrote: post #139

And you immediately lose the ability to do `crontab -l` on any server to know its scheduled tasks. Now you get to look around the myriad of places where you can put systemd files, and figure out which ones are base services and which ones are custom, with no general convention to go about it. Nope.

/etc/crontab /etc/cron.d/* /etc/cron.hourly/* /etc/cron.daily/* /etc/cron.weekly/* /etc/cron.monthly/* /var/spool/cron/crontabs/*

Bad memories. I particularly enjoyed fighting with third-party programs that installed system cronjobs in the various tabs, and having to remember to go and find them after package upgrades and try to figure out how to robustly identify when their processes were running so my other cronjobs wouldn't overload or clobber state, since the third-party-installed jobs didn't play along with any lockfile-based coordination we used. Wants/WantedBy/Requires are godsends by comparison.

Re: Love systemd timers

#199

Post by harshreality »

simoncion wrote: post #136
eqvinox wrote: post #92

Earlier quoted context omitted.

How do you express those things in a systemd timer? E.g. run something 4x per day, */6 in cron.

Sure, I'll pile on here. 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] https://www.freedesktop.org/software/systemd/man/latest/syst... > [1] This question is sarcasm. SystemD is often like this... dead simple things look dead simple, but complex thi…

I found the systemd time spec syntax you referenced to be logical and well thought out.

Cron syntax is simpler for the easy cases because cron tries to do less. It ignores years and seconds entirely, and doesn't try to adhere roughly to ISO8601 ordering and field separators, instead using space universally for field separation and euro-style least-to-most significant field ordering. I like ISO8601, so I get along with systemd's style better, despite it introducing slightly more cognitive load.

The only thing that threw me for a loop and seems like "special magic" was

> "Mon *-05~07/1" means "the last Monday in May."

But good luck doing that in one line in cron.

Some cron-style libraries seem to support L/W/# for last / nearest-weekday / nth of month, but I don't know if any system crons do. (cronie? dcron? I don't think so. fcron? bcron? I don't see it there either.) '#' is syntactic sugar for DOW + 7-day range, while L is covered by the above quoted syntax.

If your cron has that kind of syntax, then for a case like "weekday closest to 1st of month", "W" is more convenient than writing 3 systemd timer rules to cover the three cases (weekday day 1, monday day 2, friday last day of month), but that's a big if. Generally you'd have to write 3 rules in cron anyway.

Re: Love systemd timers

#200

Post by Cyph0n »

zaik wrote: post #197
Cyph0n wrote: post #28

Earlier quoted context omitted.

I define all units in Nix because: a) It is way nicer and you get decent validation at build time b) A LLM can port units over if the need arises; it’s a very light abstraction around systemd syntax c) I personally don’t see how I would ever move to another distro :)

b) Or you could take the compiled units from /etc/systemd and copy them wherever

I believe that probably won’t work unfortunately; the generated unit files have a bunch of hardcoded Nix store paths.
Post reply on HN