4 ms·

And yet despite all the problems you point out (some of which I agree with, some of which I don't) there are thousands of sysadmins happily (and some percentage

And yet despite all the problems you point out (some of which I agree with, some of which I don't) there are thousands of sysadmins happily (and some percentage greater than 0% unhappily) using systemd on hundreds of thousands of servers and enjoying the new features (and no, the new features are not limited to speed). So obviously it isn't the case that systemd objectively sucks on servers, it is the case that in your subjective opinion it does. I myself am only a hobbyists sysadmin but I -love- how easy it is to make daemons that actually start and initialize in the correct order (no more bash script loops waiting for a socket to be active!), have services run as their own user enforced at the init system level while still accessing named ports, while also having the added minor benefit of parallel startup. In my hobbyist use, I have not encountered any bugs/errors and I've been running it since debian first shipped it in testing. Obviously I don't use it as much as real sys admins, but the point remains that despite its negatives it brings plenty of positives as well.

falcolas 10y ago
To counter your anecdata with my own anecdata: I have never had a problem with a bash-script (or upstart) based init system which took more than an hour to fix once and run on every server (and I've worked with a few hundred thousand servers at various points in my career). To compare, I spent an hour reading systemd documentation to just find the location of one of the configuration files. More to the point, I have now worked for two large companies which are holding off on upgrades to systemd-based distro versions in an effort to avoid having to deal with systemd. It's such a complete paradigm shift, and so opaque, that not one of the sysadmins I've worked with is comfortable betting their jobs on it. Stupid things like the infinite loop via systemd-notify do little to ease that concern.
- mordocai 10y ago
  > To compare, I spent an hour reading systemd documentation to just find the location of one of the configuration files. And how long did it take you to figure out the same thing with sysv init when you were just starting out? I imagine it was more than 0 min. Plus now that you know where that config file is you don't have to look it up again so that cost was once... With my anecdota, I have had no end of problems with bash scripts and sysv init including non deterministic behavior. Anytime i'd run into problems I'd end up having to write complicated bash scripts myself to fix them. Note all of this is to get my applications to run, not fixing linux distribution package inits (which are generally semi well tested). If you look at the distribution package inits, they are typically as complicated as the ones I had to write just already done for you. Its a mess.
  - falcolas 10y ago
    > And how long did it take you to figure out the same thing with sysv init The answer is, and always was, '/etc/init.d'. Upstart lists its directory ('/etc/init') in the first sentence of its second paragraph. SystemD, on the other hand, requires that you first know that they are now called unit files with a .service extension. Once you have that, you can then attempt to find the man page which finally lists the possible directories they can be stored in as any one of of '/etc/systemd/system/', '/run/systemd/system', '/usr/lib/systemd/system', '~/config/systemd/user/', '/etc/systemd/user/', '/run/systemd/user/', '~/.local/share/systemd/user/', or '/usr/lib/systemd/user'. Unless you're tracking down a port opaquely owned by systemd, in which case you then also need to know that systemd refers to them as 'socket activation' services, and that those files end with .socket instead of .service. > I have had no end of problems with bash scripts and sysv init including non deterministic behavior People are running into the same determinism problems with Systemd, so it doesn't appear this is a step forward.
    - JdeBP 10y ago
      Just so that you and anyone reading this knows: that list is wrong. * http://jdebp.eu./FGA/systemd-documentation-errata.html#MissingUsrLocalLibSystemd http://jdebp.eu./FGA/systemd-documentation-errata.html#Missi...
      - falcolas 10y ago
        Thank you. I have to be honest though, at this point I just do a find for .service and .socket files anymore. > in the absence of any overriding environment variables Sigh.
        digi_owl 10y ago
        > > in the absence of any overriding environment variables > Sigh. Almost as if they are deliberately trying to make it hard...

falcolas 10y ago

To counter your anecdata with my own anecdata: I have never had a problem with a bash-script (or upstart) based init system which took more than an hour to fix once and run on every server (and I've worked with a few hundred thousand servers at various points in my career). To compare, I spent an hour reading systemd documentation to just find the location of one of the configuration files. More to the point, I have now worked for two large companies which are holding off on upgrades to systemd-based distro versions in an effort to avoid having to deal with systemd. It's such a complete paradigm shift, and so opaque, that not one of the sysadmins I've worked with is comfortable betting their jobs on it. Stupid things like the infinite loop via systemd-notify do little to ease that concern.

mordocai 10y ago
> To compare, I spent an hour reading systemd documentation to just find the location of one of the configuration files. And how long did it take you to figure out the same thing with sysv init when you were just starting out? I imagine it was more than 0 min. Plus now that you know where that config file is you don't have to look it up again so that cost was once... With my anecdota, I have had no end of problems with bash scripts and sysv init including non deterministic behavior. Anytime i'd run into problems I'd end up having to write complicated bash scripts myself to fix them. Note all of this is to get my applications to run, not fixing linux distribution package inits (which are generally semi well tested). If you look at the distribution package inits, they are typically as complicated as the ones I had to write just already done for you. Its a mess.
- falcolas 10y ago
  > And how long did it take you to figure out the same thing with sysv init The answer is, and always was, '/etc/init.d'. Upstart lists its directory ('/etc/init') in the first sentence of its second paragraph. SystemD, on the other hand, requires that you first know that they are now called unit files with a .service extension. Once you have that, you can then attempt to find the man page which finally lists the possible directories they can be stored in as any one of of '/etc/systemd/system/', '/run/systemd/system', '/usr/lib/systemd/system', '~/config/systemd/user/', '/etc/systemd/user/', '/run/systemd/user/', '~/.local/share/systemd/user/', or '/usr/lib/systemd/user'. Unless you're tracking down a port opaquely owned by systemd, in which case you then also need to know that systemd refers to them as 'socket activation' services, and that those files end with .socket instead of .service. > I have had no end of problems with bash scripts and sysv init including non deterministic behavior People are running into the same determinism problems with Systemd, so it doesn't appear this is a step forward.
  - JdeBP 10y ago
    Just so that you and anyone reading this knows: that list is wrong. * http://jdebp.eu./FGA/systemd-documentation-errata.html#MissingUsrLocalLibSystemd http://jdebp.eu./FGA/systemd-documentation-errata.html#Missi...
    - falcolas 10y ago
      Thank you. I have to be honest though, at this point I just do a find for .service and .socket files anymore. > in the absence of any overriding environment variables Sigh.
      - digi_owl 10y ago
        > > in the absence of any overriding environment variables > Sigh. Almost as if they are deliberately trying to make it hard...