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

[Andrey Borzenkov]

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 :)

Anyway, it was mostly to get a feeling about generators stuff. Making
it real is a bit more involving.

>
> 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?

> 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).

But the mere fact that interface is present does not mean we want it
to be started.