Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by Nobu View Post
    So, how do the clients (or, "subsequent services") find out that the service is available normally? Is it a PID file? Does it listen on a SOCKET? How does OpenRC determine when the service is "ready"? The answer may be surprisingly similar to what you would have to do if you use systemd...but I couldn't tell you without a concrete example.

    I find all of the systemd documentation and publications helpful, regardless, for my simple usecase (a "user").
    I never stated that other init systems could do that or that there is not enough documentation. The whole point of my statement is that systemd is not able to reliably start dependent services, as long as those services are not specifically coded against the systemd libraries or its DBus interfaces. So to get systemd working as advertized you need to make your services dependent on systemd, otherwise it will not be able by design to do what people want it to do.

    And isn't the whole point (or at least one of the main points) of systemd to be able to do exactly that without having to depend on unreliable mechanisms like PID files? I smell fail here, just my opinion.

    Comment


    • (edit: fwiw, I know you didn't. I quoted the story you asked someone to point out flaws in, and I was referencing it in my question) If you want it to "just work" and other solutions aren't able to make it "just work", then what's wrong with doing it "the systemd way"? The fact is you are able to reliably start services with systemd if you choose to, and you aren't with other systems (unless I'm misreading your statement).

      Depending on dbus, or sockets, or PID files, is not the same as depending on systemd. You can use all of the above without giving a rats ass about systemd, and systemd can simply watch for the presence of their use and activate services based on that.
      Last edited by Nobu; 22 April 2014, 07:22 PM.

      Comment


      • Originally posted by Vim_User View Post
        Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/
        The part about forking processes is wrong: You may specify a PID file, yes, however, it is by no means the only way systemd uses to determine the childs of a forking daemon. The children are determined by cgroups.

        Comment


        • Originally posted by Vim_User View Post
          I never stated that other init systems could do that or that there is not enough documentation. The whole point of my statement is that systemd is not able to reliably start dependent services, as long as those services are not specifically coded against the systemd libraries or its DBus interfaces..
          You can easily hack in fixes if you have problems. In my opinion none of these are the RIGHT way to fix things but you can make them work.

          Use a ExecStartPost=/bin/sleep 3

          Or ExecStartPost=/usr/lib/service-name/wait-for-startup

          Or make a wrapper script that runs the actual service and checks for startup and call that in ExecStart.

          Comment


          • Originally posted by Vim_User View Post
            And isn't the whole point (or at least one of the main points) of systemd to be able to do exactly that [reliably start dependent services] without having to depend on unreliable mechanisms like PID files? I smell fail here, just my opinion.
            You seem to be asking systemd to fix "unreliable mechanisms like PID files" without changing anything. "Fix it without changing anything" is never going to work.

            systemd DID fix it, but had to add some new things to make it work. This is not unique to systemd. Apple OS X does many similar things.

            Comment


            • I am not asking anyone to fix anything. I am merely pointing out that systemd is not capable of doing what it is advertized to do unless the services it starts are specifically written to connect to systemd (read: introduce a dependency on systemd), either using its libraries or its DBus interfaces. Of course one could use hacks, but what would be the point of systemd in that case?

              Comment


              • Originally posted by Vim_User View Post
                I am not asking anyone to fix anything. I am merely pointing out that systemd is not capable of doing what it is advertized to do unless the services it starts are specifically written to connect to systemd (read: introduce a dependency on systemd), either using its libraries or its DBus interfaces. Of course one could use hacks, but what would be the point of systemd in that case?
                The point is that you have the ABILITY to use better methods and the hacks are smaller. The hacks are now restricted to detecting startup.

                You can get rid of all the old hacks to detect service shutdown. Repeatedly grepping ps output to kill, kill, kill, kill, kill -9 is no longer needed.

                You can get rid of guessing if your service should be at runlevel 70, 72, 75, 80 or 79 and naming things stupid names like "S00aaa-really-first-startup".

                And oh yeah, things don't go psycho if you run service blah restart in one terminal and service blah shutdown in a second terminal.

                But blah, blah, blah, everything I was about to write is well covered in all of the FAQs.

                Comment


                • Originally posted by Zan Lynx View Post
                  The point is that you have the ABILITY to use better methods and the hacks are smaller.
                  So, which abilities are that? I can't see anything that didn't exist before, possibly not so integrated, but all needed tools were there already.

                  Comment


                  • Originally posted by Vim_User View Post
                    So, which abilities are that? I can't see anything that didn't exist before, possibly not so integrated, but all needed tools were there already.
                    Let's see...parallel OR (inclusive) ordered start-up of services (as configured); automatic restart of crashed services (if desired); socket, path, device, etc. activation of services; forked daemon are tracked in cgroups, so you don't get rogue daemon if the main service dies.

                    These are just a few, the list could go on. These could maybe be done with other tools or scripts (some much less easily than others), but with systemd it's a simple unit file away. There are reasons you might not like this, I guess, but I haven't heard many good ones yet.

                    Comment


                    • There's a longer "short list" on the systemd introductory post, and a lot more (explanations of why systemd was created, what it can do, etc.). I recommend reading it if you haven't yet and you have a bit of time.

                      Comment

                      Working...
                      X