On Fri, 19.10.12 00:01, Dan Tihelka (dtihe...@gmail.com) wrote: > > Hello, > thank you for such a long and detailed answer. I do agree with you in general. > > Of course, there is an intersection of two words. On one side there is an > init > daemon being responsible for starting/stopping services. On the second side > there is an network management system/daemon handling the net connection. And > as it is true that init daemon does not have to handle network status (as you > explained), a network manager does not have to start services ... > > The way (well, you may have a better solution, probably ...) is in > communication. I can imagine that the network manager will emit dbus > broadcast > messages about network up/down, no matter what particularly it means (there > may even be several different kinds of signals). If init daemon can handle > the > dbus signals, users or admins can write services as the reactions to them. > > And here I don't mean any "standardized" set of signals which both systems > have to implement. It is enough to allow StartOnDBus="user-write-what- > require", SopOnDBus="user-write-what-require" and similar stuff. Similarly to > sockets activation or automounting capability. > > Do you think that it is the way, or am I completely mistaken?
I am a bit afraid of adding a generic rule expression language where you can match everything to do everything. Our current approach is to match on specific changes only: - If a message is sent to a service that is not started, D-Bus can ask systemd to start it. - If systemd receives an explicit request to start something it will do so. Both of these cases are kinda explicit in their behaviour, starting things can be expected to be an effect of this, it's not a hidden side-effect. But this is very different from matching arbitrary signals, where things would become much less obvious. I am tempted to say that the better approach is to make activation explicit rather than implicit with this. If you start allowing flexible expressions on which signal to start what then you will also quickly get into the territory of allowing more complex expressions too (such as, under this condition on this event do this, but under this other condition this instead), and I don't want that really. It is also a bit incompatible with the model how systemd tries to minimize loading things of disk: only when we get one of those explicit requests to start something (as mentioned above) we go to disk and try to find a unit matching this. At any given time systemd only has in memory units that are actually referenced. But if we want to allow a rule set we'd either have to go to disk on any bus signal or always load the ruleset into memory. So, nah, I am not convinced really, that this is rally so desirable. I think the best approach is probably to focus on the specific usecases, and come up with a good approach to handle those, and only if from them it becomes clear that activation-on-arbitrary-bus-signals would be cool and the best solution we should consider them. Hope that makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel