On Mon, May 07, 2012 at 09:30:42PM +0800, Patrick Lauer wrote: > On 04/26/12 00:42, Roger Leigh wrote: > > On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote: > >> I'd like to ask you to evaluate OpenRC as candidate to replace the "old" > >> have-always-been-there sysvinit/insserv init scripts in Debian. > > While as others have mentioned that ideally a more dynamic init > > system such as systemd or upstart is where I think the general > > consensus is > Define "dynamic" please, and don't use "lines of code changed per month" > as metric ;) > As long as we don't even agree what that (and "event driven") mean it'll > be needlessly confusing for all involved to discuss without a shared > vocabulary.
>From the dependency side, it looks like OpenRC has most of that functionality covered; it can start other services as required in order to bring up dependencies needed by a service before starting it. What systemd has that (AFAICS) OpenRC and sysvinit/startpar/insserv do not, is a global view of the entire running system. That is, when you run an OpenRC script, it can trigger dependencies recursively, but it doesn't have itself a dependency graph of the entire set of available services. systemd, in comparision, can read all the unit files and has a complete picture of the entire system. So in a sense, it has a higher-level view of the system--mountpoints and other stuff can go into the dependency graph, which solves som of the issues with mounting of network filesystems and bringing up interfaces, and starting the necessary services etc. The dynamic part is AFAICT a few pieces: 1) socket-based service activation 2) dbus-based service activation [and I guess others, e.g. udev, initctl, etc.] All of these are effectively the same conceptually; an external trigger causes systemd to execute actions. The socket-based activation is essentially the same as inetd, but because it's integrated into systemd it can fit this into the dependency graph, as well as starting all the listeners in a single step, and then allowing the actual services to be started on demand. The dbus activation is similar (I'm less familiar with it), but working over dbus instead. I guess this is needed for integration with desktop environments (e.g. bluetooth), in response to user actions. The other really nice thing that systemd has is a unified means of configuring the process environment for all services, e.g. resource limits, umask, etc. which are all set up before starting the service. That's not to say that OpenRC couldn't be made to do any of these things, it being a superset of the functionality currently provided. But it would probably require replacement of sysvinit as init with a daemon like systemd which could keep track of all the dependencies and other stuff, and respond to signals of various types to trigger events. It could convievably query each init script for its dependencies to build up the complete picture of the system; this could cater for reading from multiple sources like systemd does: OpenRC scripts, LSB scripts, systemd units, /etc/fstab, and /etc/inittab etc. The above type of central control is one source of confusion in our initial discussions regarding LSB script support; I initially assumed that this was how OpenRC deps were implemented, which would have made LSB script support simpler. However, it would be possible to extend the OpenRC functions to trigger the central coordinating service rather than doing things themselves, as well as to configure the per-service process environment. (I was planning on bringing this sort of possibility up, but wanted to learn more about the design of OpenRC and get it working first on Debian with LSB scripts so I had a clear understanding of what would or would not be possible or appropriate.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120507155858.ga22...@codelibre.net