Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

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

  • 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, 08: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, 12:07 PM.

          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


                    • Originally posted by chrisb View Post
                      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:



                      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.
                      The whole problem was also a bit caused by the kernel crashing on a user space program outputting too much.
                      It is also true that it's dumb to pollute different namespaces, but for that to happen, you need at least to pick a namespace, which is something neither systemd nor the kernel did.

                      Comment

                      Working...
                      X