6 ms·

I ask this in every systemd thread but I genuinely would love a real answer. Can anyone give me exact real-world examples of where systemd is objectively better

I ask this in every systemd thread but I genuinely would love a real answer. Can anyone give me exact real-world examples of where systemd is objectively better suited than any number of other init systems? The fact that I still have yet to see any such examples in the last half a decade seems pretty telling. Wouldn't and shouldn't there be tons of such examples given the rhetoric?

foldr 8y ago
It makes it a lot easier to set up a service than System V init. Writing a service file is much easier and less error prone than writing shell scripts.
- JdeBP 8y ago
  syn0byte explicitly said "any number of other init systems", and was clearly trying to avoid people trotting out, as you and several others have, the tired old fallacy, called out by the Uselessd Guy long since, of assuming that only systemd and van Smoorenburg init+rc exist ... * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235 https://news.ycombinator.com/item?id=8488235) * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/ * http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... ... and then calling the latter "System V init", when AT&T System V had actually adopted a new system with separate system and service management several years before Linux was even invented. * https://news.ycombinator.com/item?id=18788974 https://news.ycombinator.com/item?id=18788974
  - foldr 8y ago
    I took syn0byte to be asking for an example of an init system that systemd is better than. I can't really see any other interpretation of their comment. >and then calling the latter "System V init", This is what everyone calls it in the context of Linux init systems. You may not like that particular piece of terminology, but please don't give me a hard time for following the standard usage.
    - JdeBP 8y ago
      > I can't really see any other interpretation of their comment. Then you are unable to distinguish singulars from plurals.
      - foldr 8y ago
        No, the comment asks whether it's better than any number of other init systems. In other words, whether there are any other init systems that it's better than. So a counterexample could be a single init system. I see no other sensible interpretation of the sentence. Could you paraphrase what you take it to mean?
    - syn0byte 8y ago
      "any other init system..." originally included "...besides an ancient SysV strawman." but I removed it because it seemed overly snarky. Having written and dealt with both; It's about equal in my time and effort to write either in sh or windows ini/'unit' files.
      - foldr 8y ago
        If you claim that System V init is just as good as systemd, then it is a relevant comparison rather than a straw man, no? In many cases there were a substantial number of people who wanted to keep System V init rather than move to systemd (e.g. https://wiki.debian.org/Debate/initsystem/sysvinit https://wiki.debian.org/Debate/initsystem/sysvinit). System V init wasn't an ancient straw man for Debian users. It was the init system that systemd replaced.
zaarn 8y ago
If you want to container your services better, then systemd is a good choice; it has plenty of isolation options to secure yourself against misbehaving code. By default systemd will not leave any orphans lying around in your system if the service dies unexpectedly. You can also manage much more complex dependency situations (like two services being dependent on each other and requiring a restart of both if one crashes). Systemd Timers are also much more robust and predictable than piling scripts on top of cron, I use them extensively for managing backups on both servers and desktops with automatic reporting for failures.
jpdb 8y ago
It's much easier to manage an application's life-cycle in a systemd unit file than it is in sysvinit bash script. Unit files are much more declarative and self-contained compared to a bash script. And the bonus is that if you need/still want to use bash, you can do so in systemd.
rkangel 8y ago
To echo the sibling, but with some more detail: I worked on a system that (among other things) packaged up a Linux system as a network appliance. The device ran multiple daemons. I have built similar things before in a SysV world, and systemd made the following things easy: * Starting each daemon only when the system resources it needed (e.g. network up) were ready * Starting the daemons in the right order relative to each other * Putting daemon log output in syslog * Restarting when crashed (for those where it was appropriate) These all required only a few lines of systemd config, and no special coding in the application. For instance, logging was just printing to stdout/stderr and systemd took care of the rest.
aequitas 8y ago
I would like to ask the question the other way around. Now I've been using systemd for a while and gotten used to it I can't image wanting to replace systemd with a collection of scripts. Maybe systemd is not objectively better or worse. But I'm at least glad there is a standard among Linux systems so I only have to learn the quirks of one init system.
altmind 8y ago
Systemd is great if you/the company are developing your own software that need to be daemonized. Its easy to write/copy one .service file for all the distributions than to create some shell scripts/service descriptiors for a bunch of different distros. The alternative approach is to use supervisord - it also have service descriptors and does what systemd does. The last time we tried to use it(rhed6 had no systemd) we found it lacking some options important to us.
loeg 8y ago
> The fact that I still have yet to see any such examples in the last half a decade seems pretty telling. Yes, it's telling; it suggests you've had your fingers deliberately in your ears for five years.

foldr 8y ago

It makes it a lot easier to set up a service than System V init. Writing a service file is much easier and less error prone than writing shell scripts.

JdeBP 8y ago
syn0byte explicitly said "any number of other init systems", and was clearly trying to avoid people trotting out, as you and several others have, the tired old fallacy, called out by the Uselessd Guy long since, of assuming that only systemd and van Smoorenburg init+rc exist ... * http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ http://uselessd.darknedgy.net/ProSystemdAntiSystemd/ (https://news.ycombinator.com/item?id=8488235 https://news.ycombinator.com/item?id=8488235) * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/ * http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s... ... and then calling the latter "System V init", when AT&T System V had actually adopted a new system with separate system and service management several years before Linux was even invented. * https://news.ycombinator.com/item?id=18788974 https://news.ycombinator.com/item?id=18788974
- foldr 8y ago
  I took syn0byte to be asking for an example of an init system that systemd is better than. I can't really see any other interpretation of their comment. >and then calling the latter "System V init", This is what everyone calls it in the context of Linux init systems. You may not like that particular piece of terminology, but please don't give me a hard time for following the standard usage.
  - JdeBP 8y ago
    > I can't really see any other interpretation of their comment. Then you are unable to distinguish singulars from plurals.
    - foldr 8y ago
      No, the comment asks whether it's better than any number of other init systems. In other words, whether there are any other init systems that it's better than. So a counterexample could be a single init system. I see no other sensible interpretation of the sentence. Could you paraphrase what you take it to mean?
  - syn0byte 8y ago
    "any other init system..." originally included "...besides an ancient SysV strawman." but I removed it because it seemed overly snarky. Having written and dealt with both; It's about equal in my time and effort to write either in sh or windows ini/'unit' files.
    - foldr 8y ago
      If you claim that System V init is just as good as systemd, then it is a relevant comparison rather than a straw man, no? In many cases there were a substantial number of people who wanted to keep System V init rather than move to systemd (e.g. https://wiki.debian.org/Debate/initsystem/sysvinit https://wiki.debian.org/Debate/initsystem/sysvinit). System V init wasn't an ancient straw man for Debian users. It was the init system that systemd replaced.

zaarn 8y ago

If you want to container your services better, then systemd is a good choice; it has plenty of isolation options to secure yourself against misbehaving code. By default systemd will not leave any orphans lying around in your system if the service dies unexpectedly. You can also manage much more complex dependency situations (like two services being dependent on each other and requiring a restart of both if one crashes). Systemd Timers are also much more robust and predictable than piling scripts on top of cron, I use them extensively for managing backups on both servers and desktops with automatic reporting for failures.

jpdb 8y ago

It's much easier to manage an application's life-cycle in a systemd unit file than it is in sysvinit bash script. Unit files are much more declarative and self-contained compared to a bash script. And the bonus is that if you need/still want to use bash, you can do so in systemd.

rkangel 8y ago

To echo the sibling, but with some more detail: I worked on a system that (among other things) packaged up a Linux system as a network appliance. The device ran multiple daemons. I have built similar things before in a SysV world, and systemd made the following things easy: * Starting each daemon only when the system resources it needed (e.g. network up) were ready * Starting the daemons in the right order relative to each other * Putting daemon log output in syslog * Restarting when crashed (for those where it was appropriate) These all required only a few lines of systemd config, and no special coding in the application. For instance, logging was just printing to stdout/stderr and systemd took care of the rest.

aequitas 8y ago

I would like to ask the question the other way around. Now I've been using systemd for a while and gotten used to it I can't image wanting to replace systemd with a collection of scripts. Maybe systemd is not objectively better or worse. But I'm at least glad there is a standard among Linux systems so I only have to learn the quirks of one init system.

altmind 8y ago

Systemd is great if you/the company are developing your own software that need to be daemonized. Its easy to write/copy one .service file for all the distributions than to create some shell scripts/service descriptiors for a bunch of different distros. The alternative approach is to use supervisord - it also have service descriptors and does what systemd does. The last time we tried to use it(rhed6 had no systemd) we found it lacking some options important to us.

loeg 8y ago

> The fact that I still have yet to see any such examples in the last half a decade seems pretty telling. Yes, it's telling; it suggests you've had your fingers deliberately in your ears for five years.