Announcement

Collapse
No announcement yet.

FreeBSD: Sway Compositor Can Run While KDE Plasma On Wayland Is Still A Work-In-Progress

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

  • #41
    Originally posted by trasz View Post
    I seem to remember there was a kernel mechanism to boost frontend applications in Solaris, requested by the Xserver, introduced somewhere in the nineties. It's orthogonal to whether you use a shell script to run the app.
    This here with Solaris uses Zones/Solaris Containers. This is basically the Solaris version of cgroups right down to having a file system interface..

    Originally posted by trasz View Post
    One way to solve this was the Solaris... I think it was called the contracts.
    That contracts thing is like what you do with cgroups where you start a process in 1 cgroup then change it to another this did not operate ideally. Ideal is that the process would start in the correct zone/container.

    Originally posted by trasz View Post
    In FreeBSD, you get the same functionality via procctl(PROC_REAP_ACQUIRE). Again - orthogonal to shell scripts vs systemd, and much simpler than cgroups.
    PROC_REAP_ACQUIRE does not exist under Linux this is a non portable feature. Ok with the PROC_REAP_ACQUIRE alone does not do what systemd and cgroups do.

    Code:
    PROC_REAP_ACQUIRE Acquires the reaper status for the current process. Reaper status means that children orphaned by the reaper's descendants that were forked after the acquisition of reaper status are reparented to the reaper process. After system initialization, init(8) is the default reaper.
    The catch here is "after the acquisition" what happens before that or if the reaper processes crashes/terminated. For this to work there has to be a process sitting on the reaper holding it. You are not looking at shell script alone any more. If the reaper crashes/terminated you can lose your tracking as everything is now reconnected back to init(8) because its the default reaper and you now have a process leak on hand. Systemd on Linux the user space version crashes due to the association information being stored by the kernel cgroups so systemd user space can restart and pick up where it left off with no lost processes. Solaris zones/Containers have the same feature because we are looking at kernel supported again.

    Yes PROC_REAP_ACQUIRE is put up by people who have not looked at what cgroups do to see hang on there is a important reason why we want the kernel to be able to track a group of processes independent to process. Using PROC_REAP_ACQUIRE requires a process that takes a PID value and is consuming ram as well as not being error free.

    Comment


    • #42
      Originally posted by oiaohm View Post

      This here with Solaris uses Zones/Solaris Containers. This is basically the Solaris version of cgroups right down to having a file system interface..


      That contracts thing is like what you do with cgroups where you start a process in 1 cgroup then change it to another this did not operate ideally. Ideal is that the process would start in the correct zone/container.


      PROC_REAP_ACQUIRE does not exist under Linux this is a non portable feature. Ok with the PROC_REAP_ACQUIRE alone does not do what systemd and cgroups do.
      Of course it doesn't do what systemd does; that's one of its advantages: it's not a kitchen sink. The point is: implementation of the required functionality is already there.

      Originally posted by oiaohm View Post
      Code:
      PROC_REAP_ACQUIRE Acquires the reaper status for the current process. Reaper status means that children orphaned by the reaper's descendants that were forked after the acquisition of reaper status are reparented to the reaper process. After system initialization, init(8) is the default reaper.
      The catch here is "after the acquisition" what happens before that or if the reaper processes crashes/terminated. For this to work there has to be a process sitting on the reaper holding it. You are not looking at shell script alone any more. If the reaper crashes/terminated you can lose your tracking as everything is now reconnected back to init(8) because its the default reaper and you now have a process leak on hand. Systemd on Linux the user space version crashes due to the association information being stored by the kernel cgroups so systemd user space can restart and pick up where it left off with no lost processes. Solaris zones/Containers have the same feature because we are looking at kernel supported again.
      Nope - just make sure you acquire the reaper early enough; if you crash before that point, you don't have anything to reap anyway. I'm sorry, but this is quite obvious, and makes your answer... "not even wrong".

      Originally posted by oiaohm View Post
      Yes PROC_REAP_ACQUIRE is put up by people who have not looked at what cgroups do to see hang on there is a important reason why we want the kernel to be able to track a group of processes independent to process. Using PROC_REAP_ACQUIRE requires a process that takes a PID value and is consuming ram as well as not being error free.
      Quite the opposite - it's a later interface, and it's better designed simply because of its simplicity. The "consumes ram" issue you've mention is, again, not even wrong.

      Comment


      • #43
        Originally posted by trasz View Post
        Nope - just make sure you acquire the reaper early enough; if you crash before that point, you don't have anything to reap anyway. I'm sorry, but this is quite obvious, and makes your answer... "not even wrong".
        The catch you miss here its possible before a reaper can connect for a process for process to have already execve and started another process so come untracked. They way to make sure acquire the reaper/cgroup early enough is have the reaper/cgroup before the process executes anything,

        "if the reaper processes crashes/terminated" << this was a different problem.
        Please note the other problem what to-do in the case the reaper processes crashes that is if the process is started running and you have the reaper connected. The to answer that one in freebsd case the running processes are transferred back init the default reaper so now lost from being properly individually tracked. So this means PROC_REAP_ACQUIRE does not in fact work. It would be another matter if a reaper terminating under freebsd resulted in all connected processes also going down with it but that is not the case.

        Cgroups kernel maintained information connected to the process information directly does not reset because some process dies. And if you have correct started a process into cgroup there is no window for leak.

        Freebsd PROC_REAP_ACQUIRE does not tick the needed boxes.
        1) you need the ablity to assign before starting processes. So as soon as a process is started its cgroup/reaper is assigned. Linux kernel did not have this functionally early on and systemd attempted every different way you could do a latter apply of a cgroup/reaper only to find faults.
        2) Either keep on being tracked as cgroup do or terminate all process connected to a particular reaper when reaper crash as part of kernel design. Second one freebsd does not do.

        Comment


        • #44
          Originally posted by oiaohm View Post

          The catch you miss here its possible before a reaper can connect for a process for process to have already execve and started another process so come untracked. They way to make sure acquire the reaper/cgroup early enough is have the reaper/cgroup before the process executes anything,
          This can only be a problem if for some reason you don't have control over the order your code is doing things. In other words: if you use API badly, it won't work well. Not terribly surprising.

          Originally posted by oiaohm View Post
          "if the reaper processes crashes/terminated" << this was a different problem.
          Please note the other problem what to-do in the case the reaper processes crashes that is if the process is started running and you have the reaper connected. The to answer that one in freebsd case the running processes are transferred back init the default reaper so now lost from being properly individually tracked. So this means PROC_REAP_ACQUIRE does not in fact work. It would be another matter if a reaper terminating under freebsd resulted in all connected processes also going down with it but that is not the case.
          Again - this is not even wrong.

          Originally posted by oiaohm View Post
          Cgroups kernel maintained information connected to the process information directly does not reset because some process dies. And if you have correct started a process into cgroup there is no window for leak.

          Freebsd PROC_REAP_ACQUIRE does not tick the needed boxes.
          1) you need the ablity to assign before starting processes. So as soon as a process is started its cgroup/reaper is assigned. Linux kernel did not have this functionally early on and systemd attempted every different way you could do a latter apply of a cgroup/reaper only to find faults.
          2) Either keep on being tracked as cgroup do or terminate all process connected to a particular reaper when reaper crash as part of kernel design. Second one freebsd does not do.
          1. Nope, reapers are inherited
          2. In FreeBSD cgroups roughly translate to jails, but what you are saying still doesn't make much sense: why would anyone want the kernel to default to killing processes when the piece of software responsible for killing the right ones dies?

          Comment


          • #45
            Originally posted by trasz View Post
            1. Nope, reapers are inherited
            2. In FreeBSD cgroups roughly translate to jails, but what you are saying still doesn't make much sense: why would anyone want the kernel to default to killing processes when the piece of software responsible for killing the right ones dies?
            cgroups has a lot in common with jails but cgroup process tracking feature does not translate.

            https://en.wikipedia.org/wiki/FreeBSD_jail
            Jailed processes cannot interact with processes in a different jail, or on the main host. For example, the ps command will only show the processes running in the jail.
            This limitation makes freebsd jail unless for process management because its too strong of a sandbox. Like think about it you put dbus or pulseaudio in a jail different to another application this is not going to work out right.

            Why you are forced into the kill all route is lack of ablity to keep tracking going.

            FreeBSD reapers have the inherited issue is makes them not suitable. Where when a reaper dies what was connected to the reaper goes back to parent to prevent process leaks in a reaper solution you are technically required to implement reaper.

            Maybe freebsd need to make process grouping only jail.

            There is nothing is freebsd that does cgroups process management in a useful way.

            Originally posted by trasz View Post
            why would anyone want the kernel to default to killing processes when the piece of software responsible for killing the right ones dies?
            I did not say this was a nice choice. But its the choice that is left when you don't have something like cgroups to put grouping information on processes so another process can always safely pick up what left if the one monitoring crashes.

            Freebsd has a serous weakness in this department. So does the POSIX standard. Why is cgroups being used by kde/gnome/systemd... because in the lighter usage of just grouping you processes in that way that is crash proof to individual process issues is highly beneficial.

            Zones in solaris OS have the same properity as Linux cgroups where they can turn on all features and be like freebsd jail or only turn on handful of features with the bare min being just process grouping tool. That process grouping tool is what is important to prevent leaking processes and preventing those process leaks does prevent data corruption and other problems. Yes some database corruptions that have happened is because a new instance of a database is started while part of old crashed instance is still running. Yes this have historically happened on Linux freebsd...

            Comment


            • #46
              Originally posted by oiaohm View Post

              cgroups has a lot in common with jails but cgroup process tracking feature does not translate.

              https://en.wikipedia.org/wiki/FreeBSD_jail


              This limitation makes freebsd jail unless for process management because its too strong of a sandbox. Like think about it you put dbus or pulseaudio in a jail different to another application this is not going to work out right.
              How so? You can easily allow processes in a jail to talk to other processes using standard IPC mechanisms. They won't be able to eg kill outside processes - but why would you want your dbus or pulseaudio server to kill random processes?

              Originally posted by oiaohm View Post
              Why you are forced into the kill all route is lack of ablity to keep tracking going.

              FreeBSD reapers have the inherited issue is makes them not suitable. Where when a reaper dies what was connected to the reaper goes back to parent to prevent process leaks in a reaper solution you are technically required to implement reaper.
              Again - the reaper has one job; not crashing is not particularly hard.

              Originally posted by oiaohm View Post
              Maybe freebsd need to make process grouping only jail.

              There is nothing is freebsd that does cgroups process management in a useful way.



              I did not say this was a nice choice. But its the choice that is left when you don't have something like cgroups to put grouping information on processes so another process can always safely pick up what left if the one monitoring crashes.

              Freebsd has a serous weakness in this department. So does the POSIX standard. Why is cgroups being used by kde/gnome/systemd... because in the lighter usage of just grouping you processes in that way that is crash proof to individual process issues is highly beneficial.
              Cgroups are being used, because in Linux there are no alternatives.

              Originally posted by oiaohm View Post
              Zones in solaris OS have the same properity as Linux cgroups where they can turn on all features and be like freebsd jail or only turn on handful of features with the bare min being just process grouping tool. That process grouping tool is what is important to prevent leaking processes and preventing those process leaks does prevent data corruption and other problems. Yes some database corruptions that have happened is because a new instance of a database is started while part of old crashed instance is still running. Yes this have historically happened on Linux freebsd...
              The set of privileges available within the jail is configurable too. The Postgres problem you're probably referring to was a result of a wrong assumption on the Postgres side, not the lack of functionality.

              Comment


              • #47
                Originally posted by trasz View Post
                How so? You can easily allow processes in a jail to talk to other processes using standard IPC mechanisms. They won't be able to eg kill outside processes - but why would you want your dbus or pulseaudio server to kill random processes?
                dbus and pulseaudio can be working with third party parts So yes they do need to be able to kill outside processes at times but something doing that should not result in a untracked problem.

                Originally posted by trasz View Post
                Again - the reaper has one job; not crashing is not particularly hard.
                Please note I said dies not crashing. Think user error and they screw up a kill -9. Does not matter how well you write the reaper it can end up failed in production.

                Originally posted by trasz View Post
                Cgroups are being used, because in Linux there are no alternatives.
                This is not exactly true. There are alternatives like upstart used ptrace but these have their own share of issues exactly issue that freebsd reaper path runs into. Never crossed your mind trasz that Linux has equal functionality to the freebsd reaper solution without cgroups did it. That this functionality was used by different service management tools for Linux before cgroups was part of the Linux kernel.

                Originally posted by trasz View Post
                The set of privileges available within the jail is configurable too. The Postgres problem you're probably referring to was a result of a wrong assumption on the Postgres side, not the lack of functionality.
                The database problem as not only been postgres. Also this is a failure to under complex databases. Postgres databases get really complex where they are reaching out to host stuff.

                Simple question trasz jails inside jails freebsd how? Remember you can do cgroups inside cgroups. Remember postgres is a multi service beast. Yes having a process in one cgroup kill a process in another cgroup can be required functionality. Doing so should not ruin process tracking.

                By the way even when you set the most allowed privilege configuration on a jail on freebsd its still more restrictive than a cgroup bare min for just being a process tracking.

                The postgres side said about lack of functionality and the freebsd developer really did not get it.

                Comment


                • #48
                  Originally posted by oiaohm View Post
                  dbus and pulseaudio can be working with third party parts So yes they do need to be able to kill outside processes at times but something doing that should not result in a untracked problem.
                  They can work with third parties, sure, but I don't see why would anyone want to allow them to kill arbitrary processes. They are servers. They are talked to, not the other way around.

                  Originally posted by oiaohm View Post
                  Please note I said dies not crashing. Think user error and they screw up a kill -9. Does not matter how well you write the reaper it can end up failed in production.
                  Doesn't matter, system shouldn't protect the system from its admin.

                  Originally posted by oiaohm View Post
                  This is not exactly true. There are alternatives like upstart used ptrace but these have their own share of issues exactly issue that freebsd reaper path runs into. Never crossed your mind trasz that Linux has equal functionality to the freebsd reaper solution without cgroups did it. That this functionality was used by different service management tools for Linux before cgroups was part of the Linux kernel.
                  There are no alternative mechanisms for this provided by Linux; ptrace is something completely different altogether and while it can be abused in various ways, it's got nothing to do with this topic.

                  Originally posted by oiaohm View Post
                  The database problem as not only been postgres. Also this is a failure to under complex databases. Postgres databases get really complex where they are reaching out to host stuff.
                  What I'm trying to explain is, this was a single bug, which has since then been fixed.

                  Originally posted by oiaohm View Post
                  Simple question trasz jails inside jails freebsd how? Remember you can do cgroups inside cgroups. Remember postgres is a multi service beast. Yes having a process in one cgroup kill a process in another cgroup can be required functionality. Doing so should not ruin process tracking.
                  Not sure what you're asking about. You can nest jails since... decade? Two maybe? Technically every jail is inside another jail, except for prison0, commonly called "the outside".

                  Originally posted by oiaohm View Post
                  By the way even when you set the most allowed privilege configuration on a jail on freebsd its still more restrictive than a cgroup bare min for just being a process tracking.
                  Because it's kind of pointless to use jails for process tracking. In Linux you have no choice, in FreeBSD you do have a proper mechanism for this.

                  Originally posted by oiaohm View Post
                  The postgres side said about lack of functionality and the freebsd developer really did not get it.
                  Really? Can you point me at a link where it's described?

                  Comment


                  • #49
                    Originally posted by trasz View Post
                    They can work with third parties, sure, but I don't see why would anyone want to allow them to kill arbitrary processes. They are servers. They are talked to, not the other way around.
                    dbus is used to grant a user permission to perform action that they are not normally allowed. So this is not a normal server. So yes something under dbus being able to kill arbitrary processes is exactly what is required as the user process calling to dbus can be assigned the privilege todo this.

                    Originally posted by trasz View Post
                    Doesn't matter, system shouldn't protect the system from its admin.
                    This is where you are in trouble from the Linux world. Human error happens. Having the process tracking be resistant as long 1 process running that should be tracked is result in human error not being a system making mess.

                    Originally posted by trasz View Post
                    There are no alternative mechanisms for this provided by Linux; ptrace is something completely different altogether and while it can be abused in various ways, it's got nothing to do with this topic.
                    Again wrong. Look at upstart it did use ptrace and ptrace can do the same thing freebsd native mechanisms can with the same failures. You might call it abused.

                    Originally posted by trasz View Post
                    Because it's kind of pointless to use jails for process tracking. In Linux you have no choice, in FreeBSD you do have a proper mechanism for this.
                    Reaper solution in freebsd is like the old ptrace solutions on LInux for process tracking. Now you say that jails are pointless to use for process tracking.

                    The reality is no matter how much you say freebsd does not have a mechanism equal to cgroups for process tracking. You have in fact state the arguement that has caused the problem.

                    "System shoundn't protect the system from its admin" . What about automated control programs doing something wrong. What about being sure that all the information lives after a minor mistake so that the system can be repaired by the admin simple and quickly. cgroups around process done in ways that a process termination does not result in loss of tracking makes admins live a lot simpler in case of error. Make automated tools better able to cope.

                    Remember something cars have seat belts and crumple zones because a human driver is human and will make mistakes at times but that does not mean they should en up dead. Admin is human they will make mistake but the mistake should cause the min disruption, Cgroups don't stop admin from kill the wrong process. Having the group process data remain after a mistake make admin job simpler.

                    Reaper in freebsd is not design to improve administration the idiot logic you have state means freebsd developer are not going to consider the problems. Remember items like postgres db have options of automated management tools those are written by humans and are not always bug free.

                    Cgroups are not just about security. The name is clue in fact. Control groups. The first function implemented of cgroups ever was grouping of processes to make system control simpler and simpler for admin to recover in case of error on their part or by automated tools. Cgroups is like a cars seat belt it will not stop you from being 100 percent stupid but if you do use it and you do something wrong the harm is reduced.

                    trasz think about this you say don't protect from admin at all you are now in a hospital with 100 percent digital records do you want the admin when they make a error be be there with a stack of processes now hooked to PID1 with no details why they are there leading to extended down time because a critical service that you life depends on that is not restarted because of one of those lost processes. When I say the cgroup functional is like crumple zones and seat belts I am absolutely not kidding.

                    You could make the arguement that seat belts and crumple zones are to protect the car from the driver and most people today would laugh at you for being a idiot because the feature is there to protect the driver by reducing the damage the driver takes they make a mistake. Yet for some reason "System shoundn't protect the system from its admin" does not get the same response when the topic of what cgroups provides come up as it is the same mistake because cgroups are to reduce the damage to the admin from a mistake, Cgroups don't prevent admin from going out of their way to totally ruin a system if they want to..

                    Comment

                    Working...
                    X