[systemd-devel] Starting/stopping service on net connection

[Lennart Poettering]

On Fri, 19.10.12 00:01, Dan Tihelka (dtihelka at 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.