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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

281–290 of 357 posts

Re: Avoiding Complexity with Systemd

#281

Post by cpach »

1vuio0pswjnm7 wrote: post #261
cpach wrote: post #27

Earlier quoted context omitted.

IMO runit is abandonware at this point. No release since 2014. Have you looked at s6? It’s a compelling alternative.

Both runit and s6 are copies of daemontools which hasn't been updated since 2001. Try doing diffs of runit and s6 against daemontools. Are the differences are significant. What "improvements" were made. Things can be built to last, including software. That so many programmers today are not building such things (possibly they are incapabale) does not change fact that some did so in the past (whether intionally or not)…

I’m not convinced that all development that has been made on runit/s6 over the years has been superfluous.

Re: Avoiding Complexity with Systemd

#282

Post by geofft »

gwillen wrote: post #274
geofft wrote: post #271

Earlier quoted context omitted.

> the only computer available did not have journalctl This is exactly what I don't understand. This is a world where no other computer exists? I have bigger things to worry about (even if you scope the problem down to to "no other computer with journalctl installed exists on my network"). > Or if you're writing to network storage and would like to analyze the logs from your haiku box. I don't have any Haiku boxes, bu…

Note that not every journald/journalctl is created equal. It's easy to end up with logs written on one computer that journalctl on another computer can't read, even if the latter is a newer version, depending on which settings each one was compiled with (which is mostly a distro question.)

All right, then that seems like a reasonable objection to the format, not simply "It's a binary format." gzip files created anywhere can be read by any version of gzip.

A standalone (and cross-platform) journalctl file reader seems like a useful thing to have around and not a terribly difficult thing for someone to build.

Re: Avoiding Complexity with Systemd

#283

Post by einpoklum »

Nursie wrote: post #129
cpach wrote: post #120

Earlier quoted context omitted.

s6 does it well https://skarnet.org/software/s6/

Looks quite neat, though perhaps just a little more complex than systemd service files, I guess they essentially boil down to similar things. Where systemd has one file with a bunch of settings in, this is split into a directory of single-purpose files in s6. I'd hesitate to call it "better", but from a surface reading it seems roughly equivalent from a usability perspective.

I'm not familiar with s6 myself. But - the choice between a single file or multiple files in a directory is a relatively minor issue in the overall scheme of things. i.e. if s6 is "better" or "worse", it's not because of this fact.

Re: Avoiding Complexity with Systemd

#284

Post by strictfp »

WesolyKubeczek wrote: post #77

For me, systemd is the best thing since sliced bread. As a programmer, I now don't need to care about dropping privileges, managing logging, daemonization (the moment I need to do the double-fork dance again, chairs will be flying, I swear), dropping into a chroot, and do half-arsed guesses "is it up and running yet?" from a convoluted mess of shell code that looks like a bunch of hair stuck down a drain for a month.…

That's true, but you can get all that without taking over the entire system. Upstart was a more lightweigh contender to systemd which would give you all that but none of the "Enterprise Linux Userspace Daemon" crap.

Re: Avoiding Complexity with Systemd

#285

Post by Arnavion »

nh2 wrote: post #269
Arnavion wrote: post #171

Earlier quoted context omitted.

>On other distros, you often have to resort to global mutation in `/etc` that does not compose well. Why does this "not compose well" ? You don't have to override the whole unit as /etc/systemd/system/nginx.service , which would have problems if two things wanted to override different parts of the original unit. Just drop an override file in /etc/systemd/system/nginx.service.d/90-restart-always.conf with that one spe…

> Why does this "not compose well" ? Because you cannot easily write libraries/components that do this. In NixOS, other modules can override the options of other modules. For example, a a web app can set the nginx options that it needs, instead of requiring you (the admin) to "drop a file" in /etc. This is one of the reasons why on Ansible Galaxy (community repository of Ansible roles) there are 527 nginx roles [1],…

What does

    systemd.services.nginx.unitConfig.StartLimitIntervalSec = 0;
do that it doesn't require root?

If the point is that it's not manipulating a system-level nginx service but a user-level one, then writing the systemd override file in the way I described doesn't require root either.

Re: Avoiding Complexity with Systemd

#286

Post by zlynx »

AtlasBarfed wrote: post #223
birdyrooster wrote: post #62

Earlier quoted context omitted.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

I don't have a horse in the systemd vs init.d, I'm a dumb groovy programmer after all. But you are right, adoption is not enthusiastic, which to me is a massive indictment of the design and usability. We'll basically spin wheels until someone gets annoyed with it and does systemd better, or at least more modularized. My complaint? sudo systemctl means the verb cannot be autocompleted or introspected like sudo service…

The people who matter, who write init scripts, in other words the distro maintainers, were happy to switch.

Why else do you think so many distributions switched?

Yes, the resistance is noisy and stubborn Unix neckbeards. Not even Unix, since every other Unix had something similar to systemd already. LINUX neckbeards.

Re: Avoiding Complexity with Systemd

#287

Post by nine_k »

zxzax wrote: post #205
zozbot234 wrote: post #178

Earlier quoted context omitted.

https://blog.darknedgy.net/technology/2020/05/02/0/ is a 2020 post from the same blog, pointing out that these issues basically remain unaddressed. But again, this is not just some "anti-systemd" talking point; the pro-systemd side also acknowledges this! They just think sysv-init was even worse.

I honestly would like to see a better service manager than systemd, but just my opinion from following development of these things: a huge reason why it can't happen comes from underlying deficiencies in the kernel, and with Unix. The real core issues can't be addressed without a large amount of changes there, which are outside the control of a service manager.

I'd love to see a later development of a proper system manager that learns from systemd's faults and allows for compatible interfaces for transition.

Much like Pipewire exposes PulseAudio interfaces but is implemented differently.

Re: Avoiding Complexity with Systemd

#288

Post by gmmeyer »

mcspiff wrote: post #263
gmmeyer wrote: post #253

Earlier quoted context omitted.

I have never encountered the need for this and I honestly doubt you have either. Systemd fails mysteriously far less often than poorly written init files I have seen and it is honestly not that hard to debug almost every failure I've ever encountered. And I have worked on some very large scale systems with systemd. A systemd file I helped write has run many millions of times over without issue. I honestly find this c…

I’m a big fan of systemd, but we’ve definitely run into actual bugs in it. Especially the early RHEL7 days (7.0-7.3). Some were fixed upstream, some we’ve worked around, etc.

To be clear it definitely used to be more buggy, but I haven't encountered a genuine bug in a long time

Re: Avoiding Complexity with Systemd

#289

Post by WesolyKubeczek »

InvertedRhodium wrote: post #279
WesolyKubeczek wrote: post #275

Earlier quoted context omitted.

In the beginning, the road was quite bumpy, and my irk was that people's use cases were being dismissed in a very cavalier fashion: like, if I didn't think of a workflow, or a use case, or a piece of software that doesn't play nice which you cannot change, it's not valid and let it burn. Oh, and whoever points these things out, or ridicules me for this attitude, is a troll or a hater. In 10 years, though, reading rec…

There is still no way to filter application output at collection time, which can functionally make journald useless if you have an application that is too chatty, and will likely never be given that (AFAICT) there is hefty ideological opposition from the systems developers¹. ¹ https://github.com/systemd/systemd/issues/6432

Isn't this something that, to a degree, might be mitigated by rate limiting journald has?

IMO Lennart is right in that collection should be optimized to a point where it is (almost) never the bottleneck. I, personally, would put a filtering program between the chatty application and journald.

Re: Avoiding Complexity with Systemd

#290

Post by shawnz »

cout wrote: post #210
sseagull wrote: post #134

Earlier quoted context omitted.

I think the argument is really about transferablilty of skills. I already know how to manipulate compressed files because I have to do that in other places. And once you realize logs are just text files, I can immediately transfer all my skills of dealing with text files to dealing with logs. But now I have to learn another set of tools (or at least another command to convert it to text files). It's not really a huge…

I think this is exactly it. Journalctl doesn't resemble any tools I already know, so I have to look up how to use it each time. Binary logs aren't the problem; we have had those for ages (e.g lastlog). I just wish journalctl were a little more familiar.

> Journalctl doesn't resemble any tools I already know

What about "tail"?

Post reply on HN