Hacker News Reader

Comment by jeanpralo | Hacker News Reader

I still can't find a good reasons why you should use systemd, this things grows out of control and is way out of the initial scope.

Upstart was a reasonable replacement for system V I reckon, ...

View on HN

After using systemd for a few years on arch linux I no longer despise it. It does have some good features like unifying system jobs and cron jobs, faster boot, journal forward secure sealing (to detect log tampering).

I don't like its effective ownership by redhat and its monolithic nature however this can be solved in the long run by forks and standardisation.

I do have to admit to being impressed by the boot speed of Arch under Systemd.

> this can be solved in the long run by forks and standardisation.

I keep hearing this refrain, but the reality of the situation right now is that Systemd (and the other processes under the same development umbrella) are moving too quickly and are too complex for any fork to ever have a realistic chance.

Does there exist a group of people outside of RedHat who understand the internals of the whole thing well enough to even chance a fork?

The history of uselessd (q.v.) indicates that it cannot be solved by forks.

I tried really hard to learn systemd, but I am in the process now of moving to a systemd free distro. It's such a mess.

Gentoo uses OpenRC. It works awesome. I like not being surprised and I like avoiding conversation around systemd cause I don't see it (till I shell into a Debian)

I hate hate HATE systemd. That doeant mean it doesnt have its positive points, however.

Example: I love service files.

If they would just make everything modular/optional, I wouldnt hate it nearly as much

> If they would just make everything modular/optional, I wouldnt hate it nearly as much

Do you currently have a need for a piece of systemd that would work better as a standalone component?

Not so much standalone, but being able to substitute other services. Logging and service-management are two issues off the top of my head. I'd love to be able to disable those, and manage them with another service/package.

Optional, like the KillUserProcesses option?

Yes, I'm glad they made it optional. I don't like it, but being able to easily turn it off makes it a non-issue to me.

Socket activation is pretty cool.

http://0pointer.de/blog/projects/socket-activated-containers...

If you're hosting a bunch of apps for clients, but not all of them are being used all the time, then you can fit more onto one server by only activating them when they're used.

I know Pantheon does this, for example. https://pantheon.io/open-source

There has also been some discussion of integrating this functionality into kubernetes: https://github.com/kubernetes/kubernetes/issues/484

It's an interesting feature but inetd (or xinetd) did it for a long time decoupled from the boot process.

A pro for systemd doing it is maybe consistent nomenclature for service startup, but a con is that it couples in yet another use case to systemd which may lead to a higher risk of security, maintainability problems down the line.

I'm not sure why starting services two different ways would lead to fewer security problems. Seems like a classic example of reducing surface area for attack. One way to start services means one pile of code to audit, one configuration syntax to understand (that it's new is a negative, but that it is declarative rather than procedural in the case of initscripts is a huge win; xinetd is also declarative, so systemd is converging on the known better way to configure starting services), one place to look when figuring out what is running and what is supposed to be running on your system.

There have been init bugs in the past. There have been xinetd bugs in the past (and inetd was occasionally notorious with regard to security, though it was usually the services it provided access to rather than inetd itself). There will be bugs in systemd. But, how does consolidating service startup into one project increase the risk?

Well for one, systemd hooks to a large number of functions/subsystems that used to be more isolated. Logging, udev, dbus, churn, networking functions, etc. So it's a bit of a judgement call to say it has a larger or smaller attack surface than separating the functions out. I don't know how to really quantify if in the end it ends up more risky one way or another.

And yet, socket activation is nothing new:

inetd: https://en.wikipedia.org/wiki/Inetd

xinetd: https://en.wikipedia.org/wiki/Xinetd

Used in the "olden" days to allow a single server to serve a bunch of services, not all of which are being used all of the time, to a bunch of clients, by only activating them when they are used.

Does systemd socket activation offer any advantages over xinetd?

Yes, it can also support local sockets as well as network sockets.

Afaik something like xinetd forks and execs a copy of the daemon for each connection and communicates over stdin/stdout.

This can work for simple services like sshd which fork for each connection anyway, but would never work for something like nginx or redis.

Avoiding extra processes is good, but it's not the end of the world to exec netcat.

That is untrue. Read about "wait"/"nowait" (in the xinetd and inetd manuals, for starters).

Ah, I must have been thinking of something like

https://cr.yp.to/ucspi-tcp/tcpserver.html

Then you'll enjoy reading about the nosh toolset and s6-networking, which both separate the listen-accept model into separate programs and have the ability to invoke "wait" servers with the listening socket.

* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa... * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/UC... * http://skarnet.org/software/s6-networking/

It has one terrifying disadvantage. The socket is opened and appears to be owned by pid 1.

I haven't seen the code that does this, but my hope is that it is perfect in every way - if not then its an open door from the internet into my server.

Thats is indeed pretty cool, the whole question is more under the way decisions are beeing taken regardless of what the community says.

But I don't really see what this sort of feature has to do in an init process. I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu*.

But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)

I think socket activation makes sense as part of the int process because of the 'activation' part. That's basically what you rely on init systems to do.

For more details about the advantages of this can be found here[1] and here[2].

[1] - http://0pointer.de/blog/projects/socket-activation.html [2] - http://0pointer.de/blog/projects/inetd.html

"I really dislike the idea of having one project handling everything on a box .... The day you have a security issue in systemd we are all fu...."

I've heard this argument a bunch, but looking at the actual systemd approach doesn't really convince me that it's the case. There are dozens of binaries, dozens of maintainers, hundreds of contributors. It's comparable to a project with a bunch of parts (think Gnome or KDE only at the systems-level), rather than one big black box that does everything.

If there were a single "systemd" program that did all the hundreds of things that the systemd system does, it would be alarming and impossible to maintain. But, it's not. They may be more tightly coupled than some like (I quite like systemd and still find it a little uncomfortably coupled in many places), but that's partially a symptom of doing a bunch of things in new ways. No one built the interfaces needed to do what systemd does in the past, so building systemd took reinventing the universe in some regards. That's actually some of what you're getting when you get "systemd"; things that aren't part of the init system, but existed in some form before and are now being replaced by systemd-provided services.

"But yeah there are some real good things in systemd, maybe they should just be taken out of it and spin up in a new project ;)"

That becomes more feasible over time. Right now, there's a lot of moving parts. Another reason for the tight coupling is that the way things work together is still evolving as people learn the shortcomings of this new architecture.

systemd is not perfect, but it is a bunch of little pieces working together. A security issue in one of those pieces doesn't necessarily mean we're all fucked any more than a security issue in one part of any of the old systems necessarily meant we were all fucked.

Then why is it then being pressed into service across distros?! Why not let it churn on in its own world somewhere out of the way until it settles down and the interfaces are more defined?

Because it would never fit a real world use case, if isn't designed in and for the real world. Software built in a secret lab and trotted out to people after the fact is not the way Open Source works. We build the plane as it flies. It's always been that way in Linux.

I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem. I mean, hell, just the move from procedural to declarative for service configuration is huge. The size of that improvement really cannot be overstated.

> "I'm surprised there's still so much rage about systemd. It's not a bad solution to the problem."

You can only be surprised if you've got blinders on. Systemd has some real technical superiority but also some questionable or worse technical decisions. Beyond that, it has a truly horrible community around it that has an incredible track record for being bad at justifying shaking things up and bad at easing migration pains and bad at responding to valid criticisms or accommodating use cases different from their own. A project can't trigger flamewars this reliably and be innocent in the matter. You don't see the same kind of social and organizational conflict surrounding the major Linux display stack overhauls over the past decade.

GPL vs BSD has triggered flamewars reliably and for decades. Which one is guilty?

Not so much a secret lab, as a development fork that is maintained in parallel to shake down and stabilize before being put into the wider use.

Look at the kernel, where larger charges are developed and tested outside the main tree, and then applies for inclusion.

Never mind Torvalds' mantra about not breaking user space. Sadly user space seems highly adept at breaking itself repeatedly...

> I'm surprised there's still so much rage about systemd.

Didn't you hear? It hangs up processes which have been run with nohup!

> I really dislike the idea of having one project handling everything on a box

Whatever you do, don't switch to a BSD.

I find it frustrating that systemd's socket activation API is via library calls and not a protocol. This makes it necessary for separate support in programs to support systemd rather than having a generic mechanism that all init systems might use.

Anyone taking bests on said frustration being intentional?

`libsystemd` just provides an implementation of the socket-activation protocol. It is documented and can be implemented easily without libsystemd: after all it's in the end just reading which file descriptors to use as listening sockets from an environment variable.

Systemd is useful; assuming your goal is to turn Linux into Windows. Personally, I would rather use a well crafted Unix system.

Reply on news.ycombinator.com