4 ms·

Manually writing bash scripts to juggle cgroups is not "the init system supporting it". With systemd, this comes out of the box.

• bandrami 3y ago
  I mean, you (or somebody) need to write a short bash script for each service on sysv, and adding cgroup management to that isn't particularly hard. I just never understood how people find that more complex than a huge mess of unit files that transpile down to God-knows-what, but apparently people do. The user services systemd offers are legitimately cool (though shepherd does it better), I've just never personally understood how people find it "simpler" as a system service manager.
  • esarbe 3y ago
    Thanks for the clarification. But I still don't get it; have you ever _seen_ a complete init script? These things are hundreds of lines long if you want to account for stuff like PID management and restart capability and isolation. And you have to do that for every service on your system. And they are not even really portable.
    • bandrami 3y ago
      It only gets that long if you include the LSB dependency nonsense. Look at Slackware's scripts and tell me where those hundreds of lines are hiding.
      • esarbe 3y ago
        Okay. Would you mind explaining how you set up dependencies between the various services if you don't use the "LSB dependency nonsense"? What does Slackware use for that?
        • bandrami 3y ago
          You write the shell commands that start them in the order you want them started in and run that from your rc system. I stg I have no idea why people find this so hard.
          • esarbe 3y ago
            For me the hard part comes when you don't want these services run all the time, but only when needed. How'd you do that?
            • bandrami 3y ago
              Inetd, the software people mysteriously re-invent every decade or so
              • esarbe 3y ago
                And then you don't have dependencies anymore, so you're back to square one. I don't see how this is supposed to be more comprehensible or even "simpler" than a 12 lines unit file.
                • bandrami 3y ago
                  Several dozen unit files whose dependencies need not be listed in the files themselves, you mean. Which is why it's a step backwards in terms of simplicity. You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.
                  • esarbe 3y ago
                    > Several dozen unit files whose dependencies need not be listed in the files themselves Where else would you expect to declare the dependencies other than the file which defines the service? That's where I would expect to find (and add) the dependencies. > You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store. Fair enough!
      • esarbe 3y ago
        I've used this opportunity to look at some recent init files. Here's one of the first I stumbled upon. https://github.com/NagiosEnterprises/nagioscore/blob/master/startup/default-init.in https://github.com/NagiosEnterprises/nagioscore/blob/master/... It's 288 lines long; the LSB dependency nonsense is 8 lines of that. Then I looked up one for Postgres; https://wiki.postgresql.org/wiki/Lsb_conforming_init_script https://wiki.postgresql.org/wiki/Lsb_conforming_init_script This one is a whooping 356 lines long, LSB is again about 10 lines long, depending whether you count the header or not. I don't think the "LSB dependency" argument holds water.
        • JdeBP 3y ago
          The irony is that a lot of the boilerplate from both, including that massive case...esac part, has been eliminatable for about 10 years. See https://unix.stackexchange.com/a/480897/5132 https://unix.stackexchange.com/a/480897/5132. These are not "recent" at all, which is part of the problem. The wiki page largely froze in 2010, several years before the init-d-script innovation; and the people maintaining the nagios script until around 2018 never even tried to make use of init-d-script.
          • esarbe 3y ago
            It might well be that most of the boilerplate is a "solved problem" - then the question becomes; is this solution used at all? Let's have a look at a recent init file, from current Debian. I again just picked the first thing that I found, which was the openldap package: https://packages.debian.org/bookworm/amd64/slapd/download https://packages.debian.org/bookworm/amd64/slapd/download This init file too is over 200 lines long. I don't know how much of this is avoidable boilerplate, but evidently the Debian package maintainers either don't know about it or they lack the resources to implement it.