Comment by vidarh | Hacker News Reader

Comment by vidarh | Hacker News Reader

Parent Full thread

I'm sure there's room for reinventing a better systemd, but most of the attempts I've seen either fail to understand and intentionally ignore just how many things systemd simplify. I can understand wanting to decouple and simplify that, but I think a lot of the time the people trying to reinvent it do not understand the concerns that systemd solves for people.

E.g. a typical issue is process restarting. Simple. Can be done in a couple of dozen lines. Except that solves nothing for most people: If your server is spinning in place trying to start your big-proper-process-monitor, and it's failing to log anything because rsyslogd or whatever is also just spinning in place, and the boot processes that should have mounted the filesystems needed to get things working is repeatedly crashing?

You can mitigate all of that, but now you're creating a separate mechanism (maybe as simple as writing to disk, but still) for early-stage logging, and a separate mechanism and your init needs to deal with things like throttling restart and handling them and so does a separate process manager, and so on.

In order to simplify things, there's duplication of functionality all over the place.

A huge part of the architecture of systemd is down to starting to pull at that thread and untangling all of these issues. Is it perfect? No. Is it the solution to all of the concerns they've uncovered? Probably not. But what we had before was so much worse, and I'm so happy someone have had a go at addressing them.

And frankly, it's great that animosity towards systemd has motivated so many people to finally try to address this issues in other ways. Maybe one of them eventually solves what none of them did before systemd forced peoples hand.

I think for many people who are dissatisfied or angry, systemd didn't simplify things. Many people have simple use cases, and for them it made things much more complicated. Monolithic, incomprehensible, unintrospectable. It is like a modern car engine which is just a sealed black box under the hood, full of electronics. Sure, it works great, it is progress compared to before, everything is there for a reason. But you can't easily fix things yourself. And for many people, the old kind of engine was good enough.

I mean, for my simple uses, what is wrong with `sudo service nginx restart`, or `sudo killall nginx`? For many people, it is really dead simple. I get that it is not simple for everybody, but that is why we should have choice, not one-size-fits-all.

> I mean, for my simple uses, what is wrong with `sudo service nginx restart`

Not sure, but I'm using SystemD and do this literal command nearly daily. What exactly is your point here?

Good point, on Fedora 26 I see /usr/sbin/service is provided by initscripts-9.72-1.fc26.x86_64 and it's just translating the service commands into systemd equivalents.

    [chris@f26h ~]$ sudo service smartd.service status
    Redirecting to /bin/systemctl status smartd.service

An excellent summary. To me it flies in the face of UNIX' killer feature, it's simplicity. That it seems to be one guy pushing this barrow is worrying.

I don't think there's `one guy pushing this barrow' primarily because everything but Gentoo uses it. (And event then, you _can_ use it).

One company actually, called RedHat.

Canonical fought back for a while with upstart, but they lost.

See, RedHat got their assorted junk integrated tightly into GNOME (partly also KDE) and "legacy" options killed.

    It is like a modern car engine which is just a sealed black box under the hood, full of electronics.

One of those fully open source sealed black boxes?

    I mean, for my simple uses, what is wrong with `sudo service nginx restart`, or `sudo killall nginx`?

How is 'systemctl restart nginx' any harder? service is specified as 'Run System V Init Script' specifically in the man page, and there was a transition period where some scripts still were in /etc/init.d before all of them had been converted to systemd units, so at times both service and systemctl would have been present and doing slightly different things. So it makes a lot of sense that they didn't give systemctl the same name (see https://linux.die.net/man/8/service).

Why do you think killall wouldn't work? It's present by default on my Fedora machine here...

> One of those fully open source sealed black boxes?

That's a fallacy. Webkit is open source, doesn't mean it is not completely opaque to the majority of developers. I'm not concerned about the legal free/open source status here, but about how well a casual user can grasp and change things (that is someone who has to start, stop, maybe install services, and isn't a systemd developer).

I'm not bothered that the name of the tool is now `systemctl` of course. My problem is that is does way to many things. Want to list services? It shows you hundreds of pseudo-service-objects. They can get activated at any time by mysterious means. If you need this, it's great that it is available, but for me, the old ways (as many failings that they had) were good enough.

All of those dependencies were there before too. You just didn't have nearly as good visibility into them.

> But you can't easily fix things yourself. And for many people, the old kind of engine was good enough.

I'm not sure that's a good argument. If you have a medical problem, do you try to use it yourself?

Do you wish that you were able to fix your computer CPU when it breaks or do you just buy another? If you were to make your car/computer more fixable, it would probably be more expensive/less reliable/...

an init system is software and we're software people. It's not at all like a non doctor making decisions about medications.

I don't understand the difference between 'sudo service nginx restart' and 'sudo systemctl restart nginx' and also 'sudo killall nginx' still works with systemd. So I'm not understanding the simple use example.

Whether SysVinit scripts or systemd scripts, you have to learn something to do either one. I just see it as a difference rather than which is simpler. But systemd can use SysVinit scripts anyway if you prefer it.

The latter is a lie for more advanced scripts like what OpenRC provides.

I don't think that is a simple use case of an init system; using pre-built init scripts is the default use case. A simple use case is writing your own simple startup scripts for your own services. For that case, systemd is very, very easy to use

I find the "monolithic, incomprehensible, unintrospectable" complaint particularly odd. It has made it so much easier to slice and dice logs, make sure you have logs in almost any conditions, massively increase the ability to request information about running processes, and how they are related etc. "systemctl status [service]" alone is sufficient justification for system. Being able to get resource usage per service instead of just per process with "systemd-cgtop" too. "systemd-analyze" is also fantastic (try "systemd-analyze time" and "systemd-analyze blame" and "systemd-analyze critical-chain"). Systemd have made it vastly easier to learn about the boot process without being forced into intrumenting dozens of shell scripts.

As for simple incantations, "sudo service nginx restart" works just fine on Debian with systemd. It's trivial to provide wrappers. But not exactly hard to learn "sudo systemctl restart nginx" as an alternative. There is a small but real learning curve to replace your old habits, yes.

As for "sudo killall nginx" it is indeed easy, but it's also an awful habit. Suddenly you're on a server with multiple different nginx instances (in different containers, perhaps; been there, killed those by accident; stopped using killall). Or you're applying killall to a process that will leave a mess. Or you have a server process that spawns children that double-fork and won't die just because you've killed the server.

That simple case is indeed simple. Until it isn't. And that's one of the many caveats where systemd goes far further than most of the alternatives by e.g. using cgroups to keep track of related processes even when they do stupid stuff to confuse you. In return you get to do "sudo systemctl stop [unit]" and know that not only will it be stopped properly - along with all related processes, but any other dependencies will get shut down cleanly.

We do have choice, but in most cases where the "dead simple" cases matter, it is a matter of relearning a handful of commands (with wrappers for some helpfully provided by some distros) for the dead simple cases to work, with the bonus that all kinds of ugly corner cases most people don't even think about just stops being a concern.

If your needs are dead simple, then systemd is dead simple too. When your needs are not dead simple, most of the alternatives can't solve them properly, and you often end up having to cobble together awful monstrosities. Or trying to figure out what in the world went wrong.

Reply on news.ycombinator.com