Le 16/09/2016 18:32, Steve Litt a écrit :
On Fri, 16 Sep 2016 12:24:45 +0200
Didier Kryn <k...@in2p3.fr> wrote:

      Steve,

      I like more and more this idea of separating the tasks:
       - pid1 (sysvinit or whatever) performs one-shot startups and
basic supervision (like for getty),
sysvinit, right? Spawn your gettys and run the rc files, which run the
supervisor. Is that what you mean?

Rather the following: sysvinit spawns your gettys and your supervisor, and runs the rc files.

       - services needing a sophisticated supervisor use a supervisor
which is only a supervisor, not pid1,
This could be daemontools-encore or runit or s6.

       - services which depend on conditions use specialized tools to
wait for these conditions.
Does OpenRC do the conditional starts?

The architecture I had in mind looks something like this:

.--------.                       .----------------.
|sysvinit|     .------. run as   |runit supvisr or|
|  PID1  |-----|OpenRC|----------|daemontools or  |
`--------'     `------' daemon   |s6 supervisor   |
   |              |               `----------------'
   |-getty1       `-most processes    |-httpd
   |-getty1                           |-sshd
   |-...                              `-Other respawnables
   `-getty6


Yes, or the following, where runit etc is respawned automatically by sysvinit.

.--------.
|sysvinit|
|  PID1  |  .----------------.
`--------'  |runit supvisr or|   |-httpd
  |---------|daemontools or  |---|-sshd
  |         |s6 supervisor   |   |-other supervised servers
  |         `----------------'
  |-getty1
  |-getty1
  |...
  |-getty6  .-------------------.
  |         | whatever          |
  |---------| launch-and-forget |---|-other services
            | rc                |
            `-------------------'

   But this makes sense only if the supervisor (runit, s6, etc) has a smarter 
way to keep track of its children than wait(). For example, it could keep some 
named pipe connection to each of them. I haven't explored the ways to do that, 
though.


_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to