4 ms·

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

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.

cmurf 9y ago
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.
- AstralStorm 9y ago
  The latter is a lie for more advanced scripts like what OpenRC provides.
tokenizerrr 9y ago
> 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?
- cmurf 9y ago
  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
ohreally123 9y ago
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.
- proaralyst 9y ago
  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).
  - AstralStorm 9y ago
    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.
stephen_g 9y ago
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 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...
- captainmuon 9y ago
  > 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.
  - vidarh 9y ago
    All of those dependencies were there before too. You just didn't have nearly as good visibility into them.
21 9y ago
> 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/...
- gkya 9y ago
  an init system is software and we're software people. It's not at all like a non doctor making decisions about medications.
qyv 9y ago
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
vidarh 9y ago
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.

cmurf 9y ago

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.

AstralStorm 9y ago
The latter is a lie for more advanced scripts like what OpenRC provides.

tokenizerrr 9y ago

> 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?

cmurf 9y ago
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

ohreally123 9y ago

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.

proaralyst 9y ago
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).
- AstralStorm 9y ago
  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.

stephen_g 9y ago

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

captainmuon 9y ago
> 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.
- vidarh 9y ago
  All of those dependencies were there before too. You just didn't have nearly as good visibility into them.

21 9y ago

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

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

qyv 9y ago

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

vidarh 9y ago

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.