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: 0) by Anonymous Coward on Saturday October 17 2015, @02:51AM

    by Anonymous Coward on Saturday October 17 2015, @02:51AM (#250943)

    ...if it were out of the hands of Lennart Poettering, freedesktop, and all of the ignorant kiddies who don't understand the nuances of running mission-critical systems.

    Don't get me wrong, one of systemd's best features is its robust dependency tree processing, leading to ultra-fast start times. But systemd is still immature. The "5 years" quoted don't really count; it's only been about 1 to 3 years since EVERY distro foisted systemd on their users without a proper long-term shakedown. It makes me think of Paul Biggar of circleci, saying in his app development diatribe "It really is the future," that "We built REST and AJAX and JSON over the corpses of SOAP and CORBA, using the lessons we learned while building them."

    We need to build something on the corpse of systemd, which so hastily dispatched of the venerable but agreeable init. Hopefully this will be done while keeping activist stewards Red Hat and Canonical at two swords length.

  • (Score: 2) by sjames on Monday October 19 2015, @07:09AM

    by sjames (2882) on Monday October 19 2015, @07:09AM (#251721) Journal

    That is one of my problems with systemd, unlike SysV init, it is not at all willing to play nice with others. You either use it or rip it out. There is no just use it for these services after booting or I'd like to replace this bit with something else. It's their way or the highway. I choose the highway.