Stories
Slash Boxes
Comments

SoylentNews is people

Suggestions for Init System Features?

posted by LaminatorX on Sunday November 23 2014, @01:39AM   Printer-friendly
from the first-do-no-harm dept.

Subsentient writes:

I am the maintainer of the Epoch Init System, a single threaded Linux init system with non-intrusiveness in mind, and I'm preparing to release 2.0. It's mostly a code cleanup release, but while I'm at it, I thought I'd ask the Soylent community what features they'd like to see. I'm open to all good ideas, but I'm wary of feature creep, so as a result, I won't consider the following:

* multithreaded/parallel services, because that goes against design goals of simplicity and harms customizability
* mounting support or networking support; it's an init system, use busybox if you need a mount command.

So what do soylentils want to see in the next release of the Epoch Init System?

 
This discussion has been archived. No new comments can be posted.
Suggestions for Init System Features? | Log In/Create an Account | Top | 50 comments | Search Discussion
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, Insightful) by Arik on Sunday November 23 2014, @02:40AM

    by Arik (4543) on Sunday November 23 2014, @02:40AM (#119010) Journal
    If I were designing an init system here's the basic idea I would try to implement. It's often said to 'do one thing' but I think that oversimplifies; I prefer 'make it as simple as possible but no simpler.' Often that means 'do two things, no more, no less.'

    The first process launched must be PID1 (correct me if I am wrong.) So PID1 must be involved in the init system, but does not have to *be* the init system by itself. So we would start with an incredibly simple initial module, to occupy PID1. It would do nothing but 1) launch the actual init system and 2) re-parent orphans.

    The next process, PID2, would be the actual init system. It would start handle the rest of startup until you get to your root prompt (or a display manager if you prefer,) register an orphan handler with PID1, and then exit until the machine reboots.

    Daemon supervision, if needed, should be done with a separate program, ideally one which will also take the role of orphan handler.

    Well just some ideas, I am no kernel hacker, feel free to tear them apart.

    --
    If laughter is the best medicine, who are the best doctors?
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Interesting=1, Overrated=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   3  

  • (Score: 2) by kaszz on Sunday November 23 2014, @03:16AM

    by kaszz (4211) on Sunday November 23 2014, @03:16AM (#119016) Journal

    Then you are paying the price of two processes and IPC between them instead of one doing it the traditional way. Though it may have benefits, but they seem unclear at the moment.

    • (Score: 2, Interesting) by khallow on Sunday November 23 2014, @03:35AM

      by khallow (3766) Subscriber Badge on Sunday November 23 2014, @03:35AM (#119022) Journal
      I've seen this proposal before. The justification is that the dirt-simple process that runs as PID 1 doesn't have anything in it to fail. And the PID 2 process can be restarted without incident. This means, so I've been told, that you can upgrade the init program without rebooting the machine, which apparently is a problem with systemd.

      • (Score: 3) by Subsentient on Sunday November 23 2014, @04:46AM

        by Subsentient (1111) on Sunday November 23 2014, @04:46AM (#119036) Homepage Journal

        You can still do that. Epoch uses IPC to transfer its process state information to the updated copy. 'epoch reexec' is all that's needed to upgrade all the way from 1.0 to the current master. And it's a *full* update.

        --
        "It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti

        • (Score: 2) by sjames on Sunday November 23 2014, @02:16PM

          by sjames (2882) on Sunday November 23 2014, @02:16PM (#119103) Journal

          Surely the state should be serialized to disk in case the new instance crashes.

    • (Score: 2) by maxwell demon on Sunday November 23 2014, @11:59AM

      by maxwell demon (1608) Subscriber Badge on Sunday November 23 2014, @11:59AM (#119074) Journal

      Given that the only thing that PID1 in that proposal does, other than starting PID2, is to re-parent orphans, I don't see a lot of IPC taking place. From my understanding the main problem is that PID1 is handled specially by the Linux kernel, and thus any problem with PID1 will cause the system as a whole to fail. Which means that you would want to put as little as possible there.

      --
      The Tao of math: The numbers you can count are not the real numbers.