[systemd-devel] Dynamic generators (after systemd start)

[Lennart Poettering]

On Mon, 07.03.11 22:11, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> 
> On Mon, Mar 7, 2011 at 3:51 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Fri, 04.03.11 22:37, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> >
> >> I am playing with per-interface auto-generated units (for the case
> >> without NetworkManager :) ) and so far it looks quite promising -
> >> using trivial unit file and even more trivial generator I
> >> automatically get interfaces up at the correct time:
> >
> > I am not sure I am such a big fan of reimplementing NetworkManager...
> >
> 
> It has nothing to do with reimplementing NM. There is large number of
> possible ifcfg configuration that NM still does not support; nor is NM
> always used and desirable (why would you really need it on a
> unattended server with static network?) In this case having
> per-interface unit simply gives better overview and manageability
> under systemd (and it may deduce a couple of milliseconds from startup
> time :)

Well, I think the solution is to fix NM to do everything needed rather
than carrying around multiple implementations forever.

Regardless whether your configuration is dynamic or not, it is the right
thing to manage it with a daemon of some kind, and one that is not systemd.

But anyway, I am not sure this is the right place to discuss NM.

> > Well, sure. "systemctl daemon-reload" will drop the generator-generated
> > units files and rerun the generators.
> >
> 
> That's good to know.
> 
> Hmm ... assuming I have foo.target which wants one unit foo.service.
> Both had been started. Now generator adds one more unit bar.service
> that is also wanted by foo.target. Will bar.service be started then on
> daemon-reload?

No. A daemon-reload never causes additional services to start. It really
just reloads the configuration, doesn't actually change the system
change beyond that.

> > I'd probably recommend doing this the other way round. Write some tiny
> > code that can be executed from an udev rule, and then use
> > SYSTEMD_WANTS=netif at ... to hook it in?
> >
> 
> No, that is really not what I want. What we could (and actually I
> guess should) do is to add SYSTEMD_WANTS=network.target for every
> interface; then network.target could be removed from default
> activation (although in real life it likely does not make any
> difference).

Well, I think we shouldn't mix things up here. network.target is mostly
equivalent to $network in LSB, i.e. means "network is up". In a modern
world this is a weird thing to have actually, but that's what it is, and
too many other scripts depend on these semantics, regardless how broken
they are.

What you are now asking for is a target "network devices around",
similar to how we have bluetooth.target. If we want this (and we
probably do) we should call this "netdevice.target" or so, do
duistingish it from "network is up".

IIUC then you have network devices you want to configure and wait for
during boot, and those which you want to configure and not wait for
during boot. I think for both kinds you should have SYSTEMD_WANTS=, to
pull in netif at ...service, and for the first kind you additionally want a
generator which creates .wants/ links for these netif at ..service units
from network.target. That way all network devices which show up will be
configured, but only a subset of it is waited for at boot.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.