Page 21 of 25 FirstFirst ... 111920212223 ... LastLast
Results 201 to 210 of 247

Thread: Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

  1. #201
    Join Date
    Oct 2010
    Posts
    461

    Default

    Quote 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 at 07:47 PM.

  2. #202
    Join Date
    Oct 2010
    Posts
    461

    Default

    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 at 07:54 PM.

  3. #203
    Join Date
    Jul 2013
    Location
    Bordeaux, France
    Posts
    305

    Default

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

  4. #204
    Join Date
    Jan 2014
    Location
    Wonderland
    Posts
    93

    Default

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

  5. #205
    Join Date
    Oct 2010
    Posts
    461

    Default

    /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 at 11:07 AM.

  6. #206
    Join Date
    May 2012
    Posts
    546

    Default

    Quote 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

  7. #207
    Join Date
    Jan 2014
    Location
    Wonderland
    Posts
    93

    Exclamation

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

  8. #208
    Join Date
    Jun 2012
    Posts
    357

    Default

    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?

  9. #209
    Join Date
    Jan 2013
    Posts
    1,116

    Default

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

  10. #210
    Join Date
    Feb 2013
    Posts
    464

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •