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 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


    • systemd will know it crashed because it keeps track using cgroups, before somebody asks. This is completely unrelated to the service, and no configuration or patching is required for this to work.
      Last edited by Nobu; 04-25-2014, 07:54 PM.

      Comment


      • That was my point, althought it seems this kind of irony does not translate well to English :-P

        Comment


        • Originally posted by Nobu View Post
          systemd will know it crashed because it keeps track using cgroups, before somebody asks. This is completely unrelated to the service, and no configuration or patching is required for this to work.
          Yup, sounds like a nice functionality, but they also managed to break userspace with it, since this can't be normally disabled and systemd mounts "/sys/fs/cgroup/" as "ro" tmpfs (read only), while it also mounts it's own subdirectories as "rw".
          This effectively break userspace stuff like ulatencyd or custom scripts around jails used by hosting.

          Comment


          • /sys/fs/cgroup is rwx for root and r-x for all others for me, same as systemd's subdirectories. Only files user-writable in there are some symlinks, so I'm not sure what you're talking about.

            Regardless, he's already written about it, and I'm not going to argue about something I don't understand well.
            Last edited by Nobu; 04-26-2014, 11:07 AM.

            Comment


            • Originally posted by doom_Oo7 View Post
              That was my point, althought it seems this kind of irony does not translate well to English :-P
              the irony is you don't need to patch the service with systemd specific anything

              also not systemd, nor anything that was not written specifically to check if a service is running properly can know if a service is running properly
              i'd say more on this problem but i feel the audience would not care

              bdw;
              even SIGSEGV can be handled by the process that got it
              and a process can rexec itself with only minor annoyances (setting up sig handlers again)
              think about it

              Comment


              • Originally posted by Nobu View Post
                /sys/fs/cgroup is rwx for root and r-x for all others for me, same as systemd's subdirectories. Only files user-writable in there are some symlinks, so I'm not sure what you're talking about.


                $ mount
                Code:
                ......
                tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
                cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
                cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
                cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
                .....
                Like I said, it's read only mounted fs, your permissions aint gonna be worth anything in this case.

                Comment


                • This whole thread highlights the downside to Linux: Configuration hell.

                  And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?

                  Comment


                  • Originally posted by gamerk2 View Post
                    This whole thread highlights the downside to Linux: Configuration hell.

                    And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?
                    It shouldn't at all.

                    Comment


                    • Originally posted by gamerk2 View Post
                      This whole thread highlights the downside to Linux: Configuration hell.

                      And before you say anything, ask the somewhat obvious question: Why should the Kernel care about Systemd?
                      I don't think this has much to do with Linux configuration. The whole problem was caused by one developer taking an internal kernel parameter for enabling debugging, and using that parameter to also enable debugging in his user space project. His "you don't own the debug parameter" was ridiculous - it is clearly documented that the kernel debug parameter is for debugging the kernel:

                      debug [KNL] Enable kernel debugging (events log level).
                      I don't see what's so hard to understand about that. Parsing the kernel parameter in user space, using it to enable debugging in another project, and then expecting the kernel developers to fix the problems that caused, shows a distinct lack of consideration. It's also technically dumb to pollute different namespaces - what if a kernel developer wants to enable kernel debug without systemd debug, or vice versa? Well, they can't do that, because someone thought it would be a good idea to use the same parameter to control them both.

                      Comment

                      Working...
                      X