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: 5, Insightful) by fritsd on Friday October 16 2015, @12:27PM

    by fritsd (4586) on Friday October 16 2015, @12:27PM (#250511) Journal

    why is non-determinism bad?

    Well, I guess it's simpler to debug and solve a problem of the form: "my corporation's order processing system often crashes between database startup and load-leveling front-end webserver start up", rather than a problem of the form: "my corporation's order processing system crashes 17.7% of the time and everyone is yelling at me".

    Humans and computers create problems. Humans fix problems. Humans have only a limited capacity of understanding, so the init system must be structured in a "human-repairable" way otherwise it becomes byzantine, cryptic and error-prone.

    Incidentally, about fast boot times: if you hear "my corporation's order processing system can restart from a crash several times per second", YOU'RE DOING IT WRONG.

    Starting Score:    1  point
    Moderation   +4  
       Insightful=4, Total=4
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 0) by Anonymous Coward on Thursday October 22 2015, @05:50PM

    by Anonymous Coward on Thursday October 22 2015, @05:50PM (#253311)

    The pro-systemd crowd will likely spin it to say that they can spin up 1000 instances of the order processing system in second.

    See for them only two things matter, desktop and containers/VMs. And in both instances fast startup and shutdown is preferred over long uptimes (or at least it seems so given that this is what gets priority by the systemd devs).