Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Friday October 16 2015, @08:02AM   Printer-friendly
from the what,-no-apocalypse? dept.

Structural and semantic deficiencies in the systemd architecture for real-world service management

This is a in-depth architectural critique of systemd. It claims to be the first purely technical review of systemd internals, and provides a detailed analysis of several components. It criticizes on the basis of ordering related failures, a difficult to predict execution model, non-determinism in boot-order, as well as several other points.

Though many users would perceive the long processing pipeline to increase reliability and be more "correct" than the simpler case, there is little to acknowledge this. For one thing, none of jobs, transactions, unit semantics or systemd-style dependencies map to the Unix process model, but rather are necessary complications to address issues in systemd being structured as an encapsulating object system for resources and processes (as opposed to a more well-defined process supervisor) and one accommodating for massive parallelism. Reliability gains would be difficult to measure, and that more primal toolkits like those of the daemontools family have been used in large-scale deployments for years would serve as a counterexample needing overview.


Original Submission #1Original Submission #2

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by Anonymous Coward on Friday October 16 2015, @01:41PM

    by Anonymous Coward on Friday October 16 2015, @01:41PM (#250528)

    For desktop and some server usage non-determinism is not a bad thing per-se. However it makes things actually harder to debug. As you are not sure what order something happened in. Take for example you are debugging a bit of code. It blows up every 100th run. But it is doing so because some module you assume is 'there' just isnt. In fact your code is assumed to run after this other code. So now you have a new issue that did not exist before. How to 'wait' or 'force load'. Then what if you cant force it to load? What if you double load it? How long do you wait? Remember it is non deterministic and you want the OS to CLI to show up someday so you have to time out. It is not a good user experience when randomly your computer takes 5 mins to spin up when normally it takes 30 seconds.

    For a RTOS sort of situation determinism is the name of the game. These dudes figure out how many cycles something takes to run. They make sure it takes that and no more and no less. It is deterministic. They will balk at it because they have years of exp telling them otherwise. It may be 'ok' but they will not sit down while something takes 3-50 seconds to startup depending on what phase of the moon something is in. They *need* it to startup in 3 seconds. It needs to do that every single time or something physical will literally blow up.

    The *idea* of systemd is a good one. A better init system. One more like what OSX and Windows have. A nice single way to talk to the services. A nice clean way to jail them off from root. A nice clean way to handle the life cycle and dependencies between services (the network stack should be running before you spin up the proxy server sort of thing). Something all the current init systems do very well but all do differently with some holes and all of them with different commands that pretty much do the same thing. Like windows has a nice 'are you alive' ping that you do to services. You could build something like that into each app but then it is custom for every single one. OSX and Windows have a nice predefined way of doing that. systemd went off the rails thinking it should be/contain all those services. Throwing out years of work on other services with the idea 'it will be clean' when all you end up doing is creating a whole new beast with different bugs and missing features. He basically did the same thing he did with audio. Recreated the whole stack and then screwed it up *again*.

    Starting Score:    0  points
    Moderation   +3  
       Insightful=1, Informative=2, Total=3
    Extra 'Informative' Modifier   0  

    Total Score:   3