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
    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.
    aaaaaand back to square one

    Comment


    • Originally posted by Vim_User View Post
      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.
      But that does not make a dependency on systemd, as the services can still be run without.

      Comment


      • Originally posted by erendorn View Post
        But that does not make a dependency on systemd, as the services can still be run without.
        Yes.

        And even if someone wants to use socket activation or the notify calls, those can be implemented without systemd libraries. You can take their code (its a single .c file) and drop it into your project (Legally!) and your project will use those abilities if they are present and it won't die if they aren't.

        Comment


        • Originally posted by Zan Lynx View Post
          Yes.

          And even if someone wants to use socket activation or the notify calls, those can be implemented without systemd libraries. You can take their code (its a single .c file) and drop it into your project (Legally!) and your project will use those abilities if they are present and it won't die if they aren't.
          Dbus activation is pretty standard thingy and doesn't rely on systemd in any way (in fact systemd relies on [k]dbus in this respect).

          Comment


          • or you could just do it with a fork() and a pipe and have it work as intended with any init system, as pointed out
            https://sourceware.org/ml/libc-alpha.../msg00747.html
            should even be less LoC

            Comment


            • Originally posted by gens View Post
              or you could just do it with a fork() and a pipe and have it work as intended with any init system, as pointed out
              https://sourceware.org/ml/libc-alpha.../msg00747.html
              should even be less LoC
              Except without dependency handling and without tracking of child processes. You know this, it has been explained to you dozens of times.

              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. 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.
                No, it ain't, and there's no such thing as reliable starting of services in general. For this to work, the (init) system would have to be able to know in advance whether a given service will execute correctly, if it will crash at some point or even if it will start at all. (If that was possible, we'd be rid of a whole lot of problems.) What init _can_ do is guarantee a certain behavior as soon as a given service acts in a certain way, e.g. when it crashes. Which is why having a reliable init system is a good thing.

                Comment


                • Originally posted by TheBlackCat View Post
                  Except without dependency handling and without tracking of child processes. You know this, it has been explained to you dozens of times.
                  this has nothing to do with dependency handling
                  dependency handling is in .service files (in systemd-s case)
                  Last edited by gens; 04-25-2014, 10:10 AM.

                  Comment


                  • Originally posted by gens View Post
                    this has nothing to do with dependency handling
                    dependency handling is in .service files (in systemd-s case)
                    Ans how do you stop dependant services if the one they depend on cranes and you don't know it due to lack of tracking?

                    Comment


                    • Originally posted by doom_Oo7 View Post
                      Ans how do you stop dependant services if the one they depend on cranes and you don't know it due to lack of tracking?
                      If you use systemd, then you can configure it to automatically kill those processes, or allow them to continue running. If you use some other service manager, then it depends.

                      Or, if you were talking about separate services altogether, whether those services are stopped or not depends on whether you add the depending services to Wants or Requires in the dependent service, or the other which way...I'm dyslexic, okay?
                      Last edited by Nobu; 04-25-2014, 07:47 PM.

                      Comment

                      Working...
                      X