Announcement

Collapse
No announcement yet.

systemd Clocks In At More Than 1.2 Million Lines

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

  • Originally posted by lkcl View Post
    depinit (written by richard lightman) tackled and solved this issue in a much cleaner way. firstly, daemons spawned as background tasks were treated as "legacy": the default preferred option was (is) to run them as foreground processes, and depinit had the option to farm the stdin, stdout *and* stderr separately to *separate* (dependent) services. safe_mysqld, as with all daemon-spawning, was therefore entirely unnecessary and redundant.
    Sorry you have missed that deamons like apache, cups, postgresql and oracle db do spawn background tasks themselves. So this alteration does nothing major to fix process leaking.

    Originally posted by lkcl View Post
    secondly, depinit captured *all* signals, and i do mean *all*. nothing escaped, except unfortunately if testing depinit recursively (yes, this was possible), the linux kernel rather unsportingly sends all daemon-spawned signals (of orphaned processes) down to PID1, unconditionally.
    That message to PID1 does not tell you want service that orphaned process in fact came from.

    Originally posted by lkcl View Post
    depinit was (when run as PID1) capable of hunting down even fork-bombs and malicious viruses, by deploying ever-increasingly-aggressive hunt-and-kill strategies that were SLOWLY escalated.
    And killing process that have been children of background processes started by the like of cups/apache before they have completely their job.

    Originally posted by lkcl View Post
    basically, it was extremely well-engineered, and was only a few K-lines of code.
    The different true attempts to fix the PIDFILE signal and process leak problem on Linux that kind of worked as long as everything happened to go the solutions way.
    1) Upstart attempts ptrace solution this turned out to work but it also hit performance hard and made programs with anti-debugging fail and when you wanted to debug way harder.
    2) Systemd attempted cgroup + PID namespace solution to the PIDFILE problem where you cannot send signals to the right process this turns out to be ponies all the way down(this is a wacky developer quote of the problem).

    The systemd PIDFILE solution ponies all the way down.
    1) attempt to kill process start termination process inside PID namespace of target.
    2)termination process send signal.
    3) target process fails to die.
    4) termination process locks up
    5) go 1 now you have 2 processes to send signals to to kill
    Yes a well and truly growing forkbomb the PID namespace stopped from sending signal to the wrong process but ends up when things go wrong with a growing forkbomb.

    Mind you the cgroup solution works perfectly for tracking what has started what. Remember when a process is tagged with a cgroup and it loses it parent and gets connected to the PID1 you can query what service this is from. Once you know what service you can look up if that service should be running or not running and make a way smarter move than depinit blind guess.

    Originally posted by lkcl View Post
    basically, it was extremely well-engineered, and was only a few K-lines of code.
    Depinit not extremely well-engineered.
    List of problems
    1) PIDFILE problem hits this thing quite hard. Before 5.1 Linux kernel delivering a signal to correct process is kind of pot luck. This does not implement the BSD process protection either. So this broken be you using a Linux or BSD kernel or any other unix/posix kernel made in the past 2 decades..
    2) It does not in fact address the process leak problem correctly due to being overly aggressive to make up for not knowing enough.

    Depinit along with many other init need to go into the bin of historically broken. Either never used again or someone rewrites to at least deliver signals correctly on bsd kernels and on 5.1 and newer linux kernels. Basically depinit a few K-lines of code that does not work right.

    Originally posted by lkcl View Post
    systemd is unconscionable, end of discussion, and its carte-blanche deployment, IN DIRECT VIOLATION OF A DEBIAN VOTE, will continue to haunt us until distros give *all* users the FULL right not to be forced into using it.
    The big thing to remember maintainer in distributions have the right not to be constantly getting bug reports about issues caused by init under many different services. Like having a report that cups is randomally eating print jobs or after restarting cups not being able to print. They should not have to put up with this. Dropping supporting all broken init solutions fixes this problem.

    Basically I want init options that when you look at process leak and signal handling in fact stand a chance of working correctly. When you look at init systems for Linux with this requirement the list comes very short very quickly. Systemd and openrc in what you would call init systems. You would also have like docker and other container management solutions.


    You really need to read the vote carefully.
    Maintainers are encouraged to accept technically sound patches to enable improved interoperation with various init systems.
    Key words here is "technically sound" a init system that lacks proper process leak handling is not technically sound so the patch to add support for that init system is automatically not technically sound so maintainer can opt out of including it. Carte-blanche deployment with no competition with systemd is a direct result of no one getting a quality init system up yet. The idea that systemd is unconscionable forgets giving users broken by design init systems is really unconscionable as well.

    Its about time we get really strict on the requirements init systems have to pass. After 5.1 Linux kernel correct signal delivery should be expected. Currently correct tracking and handling of process leaks should be expected. Any init system not above this bar should either be scrapped or rewritten.

    Yes bsd with jails and correct signal delivery should be expecting super good init system ideas.

    I will give you systemd had way more bugs than it should be this is implementation not design issues. Items like depinit on paper implemented ideally with no defects fails on the design table because you don't have enough information in particular places to make sane choices. Fairly much all the init options designs for Linux before systemd falls into the camp of even if ideally implemented is still broken.

    Comment


    • Originally posted by oiaohm View Post
      I will give you systemd had way more bugs than it should be this is implementation not design issues. Items like depinit on paper implemented ideally with no defects fails on the design table because you don't have enough information in particular places to make sane choices. Fairly much all the init options designs for Linux before systemd falls into the camp of even if ideally implemented is still broken.
      There are design issues, though it seems to be more subjective matter. It's opponents would be MUCH happier if using systemd was truly optional, not 'you don't want systemd? HOW dare you. Prepare for huge extra effort getting past it, working out shims..". Systemd is consciously designed in a way that makes using alternatives hard. That could have been avoided and would have make opposition to it much lighter.

      Whatever benefits Linux kernel would eventually reap, it's going to end up with a sort of Lindows - all distros are akin to others. Distro-hopping used to be interesting, always something new. Now, sigh.. hundreds of clone-distros and it's only going to worsen. Prediction: amount of distros is going to decrease, eventually leaving only handful of big ones. Plus handful systemd-less.

      Comment


      • Originally posted by oiaohm View Post
        (a) I have personally tested on all of those. Solaris with SMF can also deal with process leak. (b)Cgroup and Zones deal with process leak. (c)Attempting to use cgroup/zones to deal with pidfile issues does not work out. Sun documented process leak in Solaris as one of the justification for having SMF use Zones. The first platform to deal with the process leak problem is Solaris.
        (a)You tested it when? Year-wise? Lots have changed over the years (ca 20 FreeBSD point-releases since systemd was conceived).
        (b)Let's say I employ FreeBSD but using rctl. Leaving jails out of it for now.
        (c)How come Solaris has pidfile issue? It derives from BSD and you remarked on Page 9
        Freebsd you have always been able to open a process as a file handle so locking that PID from change from the point of view of your application. In fact the first BSD kernel had this feature and the Linux kernel only starts getting that in kernel 5.1.
        Last edited by aht0; 26 May 2019, 05:16 AM.

        Comment


        • Originally posted by aht0 View Post
          There are design issues, though it seems to be more subjective matter.
          Stuff process leaks and not sending signals right and not handling hotplug and other things not right. Are not subjective problems. These a items you can create test cases for and test init systems against and watch them break or not break.

          Originally posted by aht0 View Post
          It's opponents would be MUCH happier if using systemd was truly optional, not 'you don't want systemd? HOW dare you. Prepare for huge extra effort getting past it, working out shims..". Systemd is consciously designed in a way that makes using alternatives hard. That could have been avoided and would have make opposition to it much lighter.
          You get it wrong the systemd response is why the hell are you using a broken init system. Not how dare you use alternative. You see the difference when you start talking about openrc with systemd people they are like that not ready yet but it could interesting. Openrc has design things where it could work.

          This is kind of a bias point of view. The lead init system has always changed things. sysvinit particular things when it was dominate made it way into consolekit and udev and other parts making alternative hard. Systemd is not really making alternatives init work any harder than sysvinit use to.

          Originally posted by aht0 View Post
          Whatever benefits Linux kernel would eventually reap, it's going to end up with a sort of Lindows - all distros are akin to others. Distro-hopping used to be interesting, always something new. Now, sigh.. hundreds of clone-distros and it's only going to worsen. Prediction: amount of distros is going to decrease, eventually leaving only handful of big ones. Plus handful systemd-less.
          This is rose coloured glasses. Go back and look closely at all those distributions you use to distribution hop between and notice how many back then were sysvinit.

          You can look though distrowatch. You will fairly much see that all that has happen is sysvinit distributions have become systemd distributions.

          No one was complaining when Redhat was lead developer on all the sysvinit distribution core parts from 1998 to 2013. Yes this is sysvinit, consolekit, udev.... basically all the stuff systemd replaced. Reality dominate force in Linux since 1998. Yet people have only worked this out after systemd was released. It been well and truly over due for people to get there head out the sand on this one. I was trying alternative init systems back in 1998 so I really do know how much sysvinit particular built in quirks got in way.

          There are more distributions than we have man power to maintain. So you use to distro hop to get away from one failure and move to the next distribution and hit another pack of failure. Why because you were hopping between distributions without enough resources to maintain themselves. Always something new is being rose coloured glasses there was always something new that works better as well as something new that was busted. So if the number of distributions in fact reduce this will be a good thing. Instead of making massive number of distributions we need to focus on making the core ones quality. This is truly the rescission we need to have.

          aht0 really why people backing systemd don't take your point serousally is what you are saying is not backed by historical fact. If you hated redhat/ibm controlling init development you really should have been complaining and working on alternatives since 1998 and have them fairly much good quality with a decent pool of developers behind you. Or will you simple admit that you had your head in the sand completely ignoring how much control over init development Redhat had.

          Of course to fight for alternative init will truly mean having some developer resources. Not just throw a init system out there that don't work work and con users into use it then wonder why you never get many distributions using it.

          Most of the systemd-less distributions are using init solutions that are known to be broken. Lets keep on using old broken instead of making something that in fact works and can truly go one to one with systemd in service management and win.

          Simple point stop going boo hiss.... and put something that when a person like me looks at it we cannot rip holes in it.

          "this is windows like" is commonly uses against systemd. Systemd design is not windows like. Systemd in fact Solaris like so it should be stop making Linux like Slowaris. Yes Slowaris does party come from it detecting process leaks and being slow to respond at times.

          "sort of Lindows" As soon as you use this you basically say you don't know the history of where systemd comes from. Systemd is a mix of launchd from OS X and SMF from Solaris. Windows init system is broken in lot of the same way historic BSD and Linux init systems are plus extras.

          Comment


          • Originally posted by aht0 View Post
            You tested it when? Year-wise? Lots have changed over the years (ca 20 FreeBSD point-releases since systemd was conceived).
            I have been monitoring this init issue since 1994 so so every Freebsd release from then to now.

            Originally posted by aht0 View Post
            Let's say I employ FreeBSD but using rctl. Leaving jails out of it for now.
            Does not in fact work to block leaks you need to use jails to set up a subject-id that then rctl can work with to track down and kill leaking processes.

            Originally posted by aht0 View Post
            How come Solaris has pidfile issue? It derives from BSD and you remarked on Page 9
            This is one of those historic goofs that happens when Solaris was implementing zones and SMF. They effectively lowed the security that low on zones that you could not open file handle on PID to make pidfile process unstable. So for a short time Solaris managed to create the same level of screw up Linux kernel had from day one. Yes they attempted to fix it with zones at first before fixing the goof up with signalling.

            So systemd developers and solaris SMF developers basically attempted to fix a broken pidfile problem the same way with cgroups/zones. Solaris SMF developers were able to get kernel level cooperation a lot sooner to fix zones and the pidfile break caused by the implementation of zones.

            Yes there are lot of events that happened with SMF at it start that were fixed inside the first 12 months for SMF on Solaris that have taken a decade with Systemd on Linux. So I am not highly impressed with the Systemd or Linux kernel rate of progress on these problems.

            This is why it would be a good idea to have a pidfile test case on BSD so a goof like this does not ever get though.

            Comment


            • Originally posted by grumbert View Post
              and here was me thinking this thread would not deliver fireworks since hreindl got banned
              This is the best thing that has happened to this forum in a while. I think a premium member was the one who reported it since Michael only listens to premium members about concerns.

              Comment


              • No "fireworks" here. Somewhat informative rather.

                Comment


                • Originally posted by r08z View Post
                  This is the best thing that has happened to this forum in a while. I think a premium member was the one who reported it since Michael only listens to premium members about concerns.
                  lmao did he really get banned? No wonder it's so nice these days.

                  Comment


                  • Originally posted by Weasel View Post
                    lmao did he really get banned? No wonder it's so nice these days.
                    I was waiting for this day to come honestly. That guy was the embodiment of an obsess "no lifer". He said he owned a company and was busy all day... I never believed him because if you owned a small business there is no possible way you had all that time to search through every single thread and get yourself in there just to be the last word.

                    Comment


                    • Originally posted by r08z View Post

                      I was waiting for this day to come honestly. That guy was the embodiment of an obsess "no lifer". He said he owned a company and was busy all day... I never believed him because if you owned a small business there is no possible way you had all that time to search through every single thread and get yourself in there just to be the last word.
                      If, like me, your small business is being a residential contractor in a smaller town, some days I don't have anything going on, some days I have more work than I'd like. Like, this week I have some stuff to do in an hour or two from now that'll take four or five hours and after that I don't have shit...not a single call in a week now...If I'm lucky a lot of drunk people will have broken a lot of crap over Memorial Day Weekend.

                      Not defending him, just saying I understand that "busy all day" phrase. It sounds a hell of a lot better than "busy when I have the work".

                      Comment

                      Working...
                      X