Announcement

Collapse
No announcement yet.

Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

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

  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


  • gens
    replied
    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

    Leave a comment:


  • Nobu
    replied
    /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.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


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

    Leave a comment:


  • Nobu
    replied
    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.

    Leave a comment:


  • Nobu
    replied
    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.

    Leave a comment:


  • doom_Oo7
    replied
    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?

    Leave a comment:


  • gens
    replied
    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.

    Leave a comment:


  • ceage
    replied
    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.

    Leave a comment:

Working...
X