On Mon, 07.03.11 22:11, Andrey Borzenkov ([email protected]) wrote: > > On Mon, Mar 7, 2011 at 3:51 AM, Lennart Poettering > <[email protected]> wrote: > > On Fri, 04.03.11 22:37, Andrey Borzenkov ([email protected]) 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@... 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 [email protected], and for the first kind you additionally want a generator which creates .wants/ links for these [email protected] 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
