On Tue, May 28, 2013 at 06:34:32PM +0200, Pierre Schmitz wrote: > Am 28.05.2013 18:14, schrieb Gerardo Exequiel Pozzi: > > On 05/28/2013 10:42 AM, Thomas Bächler wrote: > >>>> Proposal: stop using dhcpcd.service, replace with a udev rule that > >>>> launches instances of [email protected] for network devices as they > >>>> appear: > >>>> > >>>> # /etc/udev/rules.d/81-dhcpcd.rules > >>>> ACTION=="add", SUBSYSTEM=="net", > >>>> ENV{SYSTEMD_WANTS}="dhcpcd@$env{INTERFACE}.service" > >>>> > >>>> This potentially breaks ordering for units on network.target, but we've > >>>> never been able to guarantee that anyways using dhcpcd.service. > >>>> > >>>> d > >>>> > >>> > >>> Ouch! It does not work :( > >>> > >>> Looks like interface at this point is still named eth0, you can see on > >>> console at boot: > >>> > >>> [ OK ] Started Entropy Harvesting Daemon. > >>> Starting Initializes Pacman keyring... > >>> [ OK ] Started Login Service. > >>> Expecting device sys-subsystem-net-devices-eth0.device... > >>> [ OK ] Found device /dev/ttyS0. > >>> Starting Serial Getty on ttyS0... > >> > >> I think the INTERFACE environment variable is set before the rename. We > >> can probably fix this - maybe try $name instead of $env{INTERFACE}? > > > Interesting. Is it documented somewhere how you can interface with > systemd from within udev? Or does systemd just "listen" on these env > vars?
This is a result of systemd listening to udev events and watching specific tags and properties on interesting devices. It's documented in daemon(7) under "Device-Based Activation" and further in systemd.device(5). d
