On Mon, May 7, 2012 at 6:54 PM, Kevin Chadwick <ma1l1ists@xxxxxxxxxxx> wrote: > On Mon, 7 May 2012 17:39:35 +0200 > Tom Gundersen wrote: > >> An event-driven init system would turn this on its head, and never >> wait for "all the things to be ready", rather start things on-demand >> and whenever their dependencies are satisfied. This leads to a much >> simpler system (from the admin/system daemon developers point of >> view), but it requires the init system to keep closer control over the >> state of the system, listen to events, etc. > > But a much more complicated one from the admin/system user in terms > of troubleshooting. Also in terms of auditing. Rather than seeing what > ports are listening by default, we have to investigate (hopefully in > one location) to know what will be listened to upon any future possible > event. I hope efforts made to make that very clear. Daemons that are ported to work with the new systemd socket activation (see dbus and udev for examples, there are also plenty others) will allow this very easily. The way it works is that the sockets will be listened to at all times, even before the daemons are running. So starting a daemon would not, if it uses pure socket activation, open any new sockets. Once your daemon does eventually start, the socket will be passed to it so it can handle any connections that came in while it was not yet ready to accept them. > Thanks for the explanation, are there some examples of what this means > we can do that couldn't be done in any way outside of init before. I guess anything is always possible (bash is Turing complete, right ;-) ). That said, we'll get lots of simplifications and can drop old workarounds: We can remove arbitrary timeouts or retry-loops. Especially when it comes to usb storage we often have issues with booting too fast, so that the device is not yet ready when we try to mount it. That would no longer be a problem. Currently, we support a relatively limited number of storage configurations (combinations of lvm/md/dm/encryption). With systemd we now deal with encrypted devices in a nice way, but there is still some way to go before the whole storage stack is event-driven. Once this is the case there will no longer be any restrictions on how you combine storage devices, on top of that the code to do this will be much simpler than the current code. Also, by the fact that things are more finegrained we can deal with some dependencies which were not possible (without a refactor) before. One example could be that we want to first mount /var, then read our random-seed from /var so we can use it as a random encryption key for /tmp. If we mount /tmp and /var at the same time that's not going to work :-) Obviously we can sort this out by refactoring our initscripts a bit, but we could think of more complicated scenarios, where you do not want to have a rigid a system as what our current initscripts are. Btw, I don't know how any of this compares to OpenRC as I have not looked at it at all (I was not impressed by the PR campaign...). -t
