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

261–270 of 357 posts

Re: Avoiding Complexity with Systemd

#261

Post by 1vuio0pswjnm7 »

cpach wrote: post #27
bitwize wrote: post #20

You incur complexity with systemd. You avoid complexity with runit.

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), and some still can.

Re: Avoiding Complexity with Systemd

#262

Post by dilyevsky »

danny_sf45 wrote: post #50
stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

As a developer I prefer using systemd instead of containers to deploy Golang applications. Without (Docker) containers it is: - build Go binary and install it in production server - write and enable the systemd unit file With (Docker) containers it is: - write Dockerfile - install Docker in production server - build Docker image and deploy container in production server I get the appealing of containers when one prod…

Without docker also:

* have a production outage because your libc was updated and now your go apps (which are dynlinked against it by default) won’t start

* mess around with low level cgroup settings if you need to oversubscribe safely

* cry in a corner the second you also need some python libs installed to do some machine learning or opencv or whatever on the side

Re: Avoiding Complexity with Systemd

#263

Post by mcspiff »

gmmeyer wrote: post #253
zh3 wrote: post #246

Earlier quoted context omitted.

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

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.

Re: Avoiding Complexity with Systemd

#264

Post by yawaramin »

tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

Wow, are people seriously still fussing about this? Systemd made the call to use a more secure default, they should be applauded for it. People who want the insecure way to be the default should take it up with their distro.

Re: Avoiding Complexity with Systemd

#265

Post by yawaramin »

knorker wrote: post #163
j16sdiz wrote: post #93

Earlier quoted context omitted.

Not OP. I my experience, systemd config is simple because it handles all the complexity. Inside it’s guts, it is much more complicated than a sysv system — naturally so because it can do so much more. Those folks loves using the latest and greatest kernel function for all its glory. All works well - until it don’t. When something is broken, suddenly you have to understand all the interdependent components to debug. B…

Agree with that. It breaks catastrophically. But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that. Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart"…

> but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.

FTA:

> It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.

Re: Avoiding Complexity with Systemd

#266

Post by yawaramin »

knorker wrote: post #238
throw-8462682 wrote: post #227

Earlier quoted context omitted.

Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.

But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates). Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it? My workplace even had to install corp software that forces a reboot every N days (with warni…

> So to me this really looks like it applies neither to servers nor desktop.

It applies to both. We need desktops to boot up fast, because you said it yourself, sometimes they just need to. And no one likes waiting around for their machines to boot. Can you imagine the volume of complaints about long boot times that would come in to large-scale distros from annoyed users? That alone makes it a high priority.

And on top of that, we need servers to boot up fast, because nowadays they're virtualized and started/stopped constantly when services are scaled up and down. Can you imagine trying to scale up a fleet of servers and waiting a couple of minutes for each one to boot?

Re: Avoiding Complexity with Systemd

#267

Post by rsync »

geofft wrote: post #104
einpoklum wrote: post #100

Earlier quoted context omitted.

1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…

I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…

"I really don't understand the scenario where binary logging is a problem."

It's not a problem - it's just not UNIX.

Re: Avoiding Complexity with Systemd

#268

Post by yawaramin »

knorker wrote: post #159
throw-8462682 wrote: post #83

Earlier quoted context omitted.

Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even if you have anecdotes, to be convincing, it would have compare something like bug density to the software projects that collectively replaces. As written, your statement is unlikely to convince anyone that isn’t yet already.

It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…

If you're going to rant utter nonsense, can you please do it somewhere else?

Re: Avoiding Complexity with Systemd

#269

Post by nh2 »

Arnavion wrote: post #171
nh2 wrote: post #135

Earlier quoted context omitted.

You can override NixOS's predefined systemd settings from _outside_ using NixOS module options. This allows you to change default settings that are not optimal for your use case, without having to patch NixOS itself, or write your own unit config. For example, systemd by default permanently gives up restarting services after a few number of tries (e.g. 5), even if you have set `Restart=always`. This is suboptimal for…

>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], and in NixOS there is 1 nginx module that everybody code-reuses.

[1]: https://galaxy.ansible.com/search?deprecated=false&tags=web&...

Re: Avoiding Complexity with Systemd

#270

Post by dane-pgp »

bkor wrote: post #216
dane-pgp wrote: post #111

Earlier quoted context omitted.

I believe that Red Hat employees were some of the main contributors to Gnome, which quickly made systemd a hard requirement, forcing distros which used it as the default desktop to make systemd the default init system.

> I believe that Red Hat employees were some of the main contributors to Gnome, which quickly made systemd a hard requirement, forcing distros which used it as the default desktop to make systemd the default init system. Yet another person writing fantasy, not facts. Systemd wasn't "quickly" made a hard dependency. It was a soft dependency for ages, then eventually the release team made a mistake around systemd-login…

Perhaps my framing of the situation was a little simplistic. To provide more facts, let me point out that the question of which init system should be default in Debian was first asked[0] to the tech ctte in October of 2013, however it was already clear the previous month that the GNOME packagers were trying to make systemd the required init system[1] in Debian (which had GNOME as its default graphical environment already):

"Debian GNOME packagers are planning the same AFAIK; they rather just rely on systemd (as init system, not just some dependencies). In the end, the number of distributions not having systemd decreases."

That was written by Olav Vitters, of the GNOME Release Team, who later admitted[2] "Personally I’m totally biased and think the only realistic choice is systemd."

You could argue that any blame for this dependency therefore lies with the Debian packagers, rather than Red Hat employees, but actually, if you look into the history, there was already a push for making GNOME dependent on systemd three years earlier by none other than Lennart Poettering.[3]

Even at that time, Josselin Mouette, founder of the Debian GNOME team, obsequiously replied "I don’t have anything against requiring systemd, since it is definitely the best init system out there currently" and later acknowledged the influence Red Hat had over the direction of GNOME, saying "Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution" and "on the whole we don’t intend to diverge from the upstream design, on which a lot of good work has been done."[4]

So there was definitely pressure on Debian from GNOME to make systemd the default init, and pressure from Red Hat to make GNOME depend on systemd. Whether or not these decisions were all coordinated in advance in a smoke-filled room is beside the point, given that things worked out exactly the way such a conspiracy would have wanted.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#5

[1] https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...

[2] https://blogs.gnome.org/ovitters/2014/02/03/my-thoughts-on-t...

[3] https://mail.gnome.org/archives/desktop-devel-list/2011-May/...

[4] https://raphaelhertzog.com/2012/01/27/people-behind-debian-j...

Post reply on HN