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

241–250 of 357 posts

Re: Avoiding Complexity with Systemd

#241

Post by josephcsible »

dylan-m wrote: post #192
josephcsible wrote: post #119

Earlier quoted context omitted.

What does this have to do with job policies? Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress, since many of the packages that Red Hat made depend on it are important to the Linux ecosystem, and the other distros didn't have the resources to fork them all.

> Systemd was forced down our throats by Red Hat […] That's a very emotional take on the whole thing. As I saw it, systemd happened and the Ubuntu developers eventually concluded "well, that's better than upstart, let's use that." Plenty of other distros made the same rational decisions. Meanwhile, the GNOME developers thought "great, people are converging around a modern init system, we can actually integrate with i…

> Meanwhile, the GNOME developers thought "great, people are converging around a modern init system, we can actually integrate with it now," and so they did.

> plenty of recent features that people assume are Red Hat driven and I can assure you they definitely are not.

My claim is specifically that the people who added the hard dependency on systemd to GNOME were Red Hat employees. I'm not talking at all on who wrote or merged any other code in it.

Re: Avoiding Complexity with Systemd

#242

Post by dralley »

regularfry wrote: post #202
spinax wrote: post #161

Earlier quoted context omitted.

As a systems guy with a focus more on ops, I agree. It's not all roses - journald/journalctl and binary logging can go die in a pit of fire for example - however setting LimitNOFile= in a unit is just really, really nice (as well as CPU limits and all sorts of other cgroup/namespace needs). But let me just mention again that journald/journalctl can go die in a pit of fire - if it wasn't for everyone adding rsyslog to…

> journald/journalctl and binary logging can go die in a pit of fire for example This is, of course, not a problem, because as systemd folk are wont to point out, systemd is not, in fact, monolithic, meaning they use well-defined interfaces and can be swapped out for an alternative.

journalctl is required I believe, but you can turn it into a dumb pipe straight to syslog.

Re: Avoiding Complexity with Systemd

#243

Post by a1369209993 »

boublepop wrote: post #94
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.

It took 10 years before the “python2 will never die”-crowd finally accepted they where not going to win at that python3 was here to stay. People spend a couple of years getting used to a stack in their early carrier and then spend decades arguing that it should never change.

> the "[python] will never die"-crowd finally accepted they where not going to win

Why are you talking in the past tense? We have done no such thing. Death to python 3; long live python.

Re: Avoiding Complexity with Systemd

#244

Post by zxzax »

spinax wrote: post #237
zxzax wrote: post #213

Earlier quoted context omitted.

Ok so complain to the ops department that they need to unify their logs. That's their problem, not yours. If the company is big I would expect them to be doing that anyway, either they coalesce around a journald-type thing that aggregates the logs locally, or they'll use another centralized service like datadog, splunk, etc. Edit: If you are ops then this is your entire wheelhouse, you should be able to solve it at s…

It has been my career experience that 5+ digit employee companies more resemble Chiba City than they do the USS Enterprise.

Sure, but that's entirely the problem those centralized logging services were made to solve. You make it really easy for everyone in the company to put their logs in the right place.

Re: Avoiding Complexity with Systemd

#245

Post by cjaybo »

josephcsible wrote: post #241
dylan-m wrote: post #192

Earlier quoted context omitted.

> Systemd was forced down our throats by Red Hat […] That's a very emotional take on the whole thing. As I saw it, systemd happened and the Ubuntu developers eventually concluded "well, that's better than upstart, let's use that." Plenty of other distros made the same rational decisions. Meanwhile, the GNOME developers thought "great, people are converging around a modern init system, we can actually integrate with i…

> Meanwhile, the GNOME developers thought "great, people are converging around a modern init system, we can actually integrate with it now," and so they did. > plenty of recent features that people assume are Red Hat driven and I can assure you they definitely are not. My claim is specifically that the people who added the hard dependency on systemd to GNOME were Red Hat employees. I'm not talking at all on who wrote…

Your claims went further than that and it feels very disengenuous for you to try and walk them back now.

Re: Avoiding Complexity with Systemd

#246

Post by zh3 »

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

Wait until it automagically fails.

It may be great for less-skilled people, but for anyone running anything where it's too critical to outsource support it's then necessary to have a systemd expert inhouse (and such a person has proven extremely hard to find).

Re: Avoiding Complexity with Systemd

#247

Post by josephcsible »

cjaybo wrote: post #245
josephcsible wrote: post #241

Earlier quoted context omitted.

> Meanwhile, the GNOME developers thought "great, people are converging around a modern init system, we can actually integrate with it now," and so they did. > plenty of recent features that people assume are Red Hat driven and I can assure you they definitely are not. My claim is specifically that the people who added the hard dependency on systemd to GNOME were Red Hat employees. I'm not talking at all on who wrote…

Your claims went further than that and it feels very disengenuous for you to try and walk them back now.

When was I ever talking about changes to GNOME other than the systemd dependency? What am I walking back?

Re: Avoiding Complexity with Systemd

#248

Post by yawaramin »

pmoriarty wrote: post #147
midasuni wrote: post #13

Earlier quoted context omitted.

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

"Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years of typing cat /etc/resolv.conf" As a sysadmin, for me things like that were very, very minor issues. The main problem was that systemd had awful documentation, written by people who'd clearly never had to use systemd in anger…

The documentation (man pages) is still pretty bad. It's always a guessing game for me where to look up the config options: systemd.exec, or systemd.service, or systemd.limits, etc.

Re: Avoiding Complexity with Systemd

#249

Post by GuidoW »

forgotpwd16 wrote: post #183
GuidoW wrote: post #167

Earlier quoted context omitted.

> Use NixOS and you'll love systemd. I use NixOS but certainly not love systemd. Instead, I've created a way to replace it with s6.[1] 1: https://sr.ht/~guido/nixos-init-freedom/ Cheers, Guido.

That's nice and it showcases how Nix can create a declarative process management atop a script-based imperative manager. How is your experience with it? Also note that there's https://github.com/svanderburg/nix-processmgmt , a manager agnostic processes management framework supporting s6 among others, but your way seems a bit more straightforward.

Thanks,

My use case is to get my VPS run a web and mail service on Nixos but without the bloated binary logging of journalcontrol. The indexes in these log files change heavily between snapshots so they take up way more disk space than append-only text logs, that snapshots very well on ZFS.

My experiences while building:

- It's easy to use the config.system.services tree of the user-services (ssh, bind, caddy, etc) to create s6-services;

- Sometimes it needs a change to make it work [1] on s6;

- That same change seems oblivious to systemd. I guess it just starts the process and never bothers to monitor liveness. So much for a process management system ;-)

- Nixos packagers seems overworked, as my pull requests seem to get stuck ;-(

- Nixos use of systemd leaves a lot of decisions to resolve at boot time, decisions that I want to make at build time with s6;

- However, I cannot create a s6 dependency tree specification at build time, that's still at run time;

- Because S6 uses the service-directory to store state-files in the same directory (no /etc-/var split).

1: https://github.com/NixOS/nixpkgs/pull/122844

Re: Avoiding Complexity with Systemd

#250

Post by rcxdude »

mgbmtl wrote: post #148
axaxs wrote: post #139

Earlier quoted context omitted.

Not going to really argue here, but I have to use mlocate every single time I want to find a unit file, because there's no telling where it would be. Perhaps blame lays on the distro packager, but still, it ends up to a user being strange.

For what it's worth: systemctl | grep ssh systemctl cat sshd I find it useful to find the unit name, and 'cat' displays the location.

You can also do 'systemctl edit ' which will open up an editor in which you can see the existing configuration and edit the overrides in /etc/
Post reply on HN