Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Am 24.05.2013 16:04, schrieb Gerardo Exequiel Pozzi:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
Shouldn't we rather fix our network setup? We actually want to present these new names during setup so that people know what they'll get after installation.
I am unsure of how to fix that, but the problem is that Kay denies that this is a problem in udev. Systemd/udev always claimed you need to listen on netlink for interface changes, now they claim you need to listen on netlink AND udev for those changes, which seems pretty redundant. IMO, the kernel should not notify netlink until udev is finished processing the uevent - that is nothing we can implement now, so let's look for something else.
1) Use networkmanager? No idea, at least LAN will work OOTB. 2) Wait for dhcpcd start until all network interfaces are settled? Would only solve the problem on boot, not with dynamically appearing network interfaces. 3) Fix dhcpcd to listen on udev? No idea how hard that is. 4) Dynamically launch dhcpcd from udev when an interface appears (SYSTEMD_WANTS="dhcpcd@$name.service")? May work.
On 05/24/2013 11:27 AM, Thomas Bächler wrote:
Am 24.05.2013 16:04, schrieb Gerardo Exequiel Pozzi:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
Shouldn't we rather fix our network setup? We actually want to present these new names during setup so that people know what they'll get after installation.
I am unsure of how to fix that, but the problem is that Kay denies that this is a problem in udev. Systemd/udev always claimed you need to listen on netlink for interface changes, now they claim you need to listen on netlink AND udev for those changes, which seems pretty redundant. IMO, the kernel should not notify netlink until udev is finished processing the uevent - that is nothing we can implement now, so let's look for something else.
- Use networkmanager? No idea, at least LAN will work OOTB.
- Wait for dhcpcd start until all network interfaces are settled? Would
only solve the problem on boot, not with dynamically appearing network interfaces. 3) Fix dhcpcd to listen on udev? No idea how hard that is. 4) Dynamically launch dhcpcd from udev when an interface appears (SYSTEMD_WANTS="dhcpcd@$name.service")? May work.
Option 4 does not work. See response in other email.
5) Disable dhcp at startup? Just like in old isos. This enforce to the user to know the net-if name at all.
Also remamber that if you boot from PXE, network rename is not posible. (I guess can be if just after all files copied, shutdown net-if)
@Pierre: I will release archiso-9 on 31 May, with or without any fix for this issue.
Am 28.05.2013 14:49, schrieb Gerardo Exequiel Pozzi:
@Pierre: I will release archiso-9 on 31 May, with or without any fix for this issue.
I have tested it and I am fine with pushing a new release; right away if you like.
Greetings,
Pierre
On 05/30/2013 05:07 AM, Pierre Schmitz wrote:
Am 28.05.2013 14:49, schrieb Gerardo Exequiel Pozzi:
@Pierre: I will release archiso-9 on 31 May, with or without any fix for this issue.
I have tested it and I am fine with pushing a new release; right away if you like.
Greetings,
Pierre
Thanks for another test. Yes works fine here, I made many boots. I just pushed a new release now and marked as complete in TODO ;)
Have a nice day!
PS: I just made a small mistake, tagged before final commit "prepare release", but fixed too quickly with "git push -f origin v9".
Am 30.05.2013 17:36, schrieb Gerardo Exequiel Pozzi:
On 05/30/2013 05:07 AM, Pierre Schmitz wrote:
Am 28.05.2013 14:49, schrieb Gerardo Exequiel Pozzi:
@Pierre: I will release archiso-9 on 31 May, with or without any fix for this issue.
I have tested it and I am fine with pushing a new release; right away if you like.
Greetings,
Pierre
Thanks for another test. Yes works fine here, I made many boots. I just pushed a new release now and marked as complete in TODO ;)
Have a nice day!
PS: I just made a small mistake, tagged before final commit "prepare release", but fixed too quickly with "git push -f origin v9".
Thanks; I'll upload a new ISO image onFriday/Saturday; hopefully before the /usr move. :-)
Greetings,
Pierre
On 05/30/2013 01:18 PM, Pierre Schmitz wrote:
Am 30.05.2013 17:36, schrieb Gerardo Exequiel Pozzi:
On 05/30/2013 05:07 AM, Pierre Schmitz wrote:
Am 28.05.2013 14:49, schrieb Gerardo Exequiel Pozzi:
@Pierre: I will release archiso-9 on 31 May, with or without any fix for this issue.
I have tested it and I am fine with pushing a new release; right away if you like.
Greetings,
Pierre
Thanks for another test. Yes works fine here, I made many boots. I just pushed a new release now and marked as complete in TODO ;)
Have a nice day!
PS: I just made a small mistake, tagged before final commit "prepare release", but fixed too quickly with "git push -f origin v9".
Thanks; I'll upload a new ISO image onFriday/Saturday; hopefully before the /usr move. :-)
Greetings,
Pierre
I will made in few hours a new release v10 with cosmetic syslinux help text width fixed FS#35533 and updated packages.both due recently "lilo" removed from repos FS#35561
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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
On 24 May 2013 22:27, "Dave Reisner" d@falconindy.com wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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.
This seems like the correct approach to me.
Cheers,
Tom
On 05/24/2013 02:15 PM, Tom Gundersen wrote:
On 24 May 2013 22:27, "Dave Reisner" d@falconindy.com wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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.
This seems like the correct approach to me.
Cheers,
Tom
OK guys, thanks for the feedback and the workaround. I will do some basic tests with it.
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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...
finally in the journal:
May 24 23:24:27 archiso login[184]: ROOT LOGIN ON ttyS0 May 24 23:25:27 archiso systemd[1]: Job sys-subsystem-net-devices-eth0.device/start timed out. May 24 23:25:27 archiso systemd[1]: Timed out waiting for device sys-subsystem-net-devices-eth0.device. May 24 23:25:27 archiso systemd[1]: Dependency failed for dhcpcd on eth0. May 24 23:25:27 archiso systemd[1]: Starting Network. May 24 23:25:27 archiso systemd[1]: Reached target Network. May 24 23:25:27 archiso systemd[1]: Startup finished in 2.349s (kernel) + 1.212s (initrd) + 1min 31.996s (userspace) = 1min 35.559s.
On May 24, 2013 7:29 PM, "Gerardo Exequiel Pozzi" vmlinuz386@yahoo.com.ar wrote:
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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...
finally in the journal:
May 24 23:24:27 archiso login[184]: ROOT LOGIN ON ttyS0 May 24 23:25:27 archiso systemd[1]: Job sys-subsystem-net-devices-eth0.device/start timed out. May 24 23:25:27 archiso systemd[1]: Timed out waiting for device sys-subsystem-net-devices-eth0.device. May 24 23:25:27 archiso systemd[1]: Dependency failed for dhcpcd on eth0. May 24 23:25:27 archiso systemd[1]: Starting Network. May 24 23:25:27 archiso systemd[1]: Reached target Network. May 24 23:25:27 archiso systemd[1]: Startup finished in 2.349s (kernel)
OK but what did you call the rule?
- 1.212s (initrd) + 1min 31.996s (userspace) = 1min 35.559s.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 05/24/2013 09:05 PM, Dave Reisner wrote:
On May 24, 2013 7:29 PM, "Gerardo Exequiel Pozzi" vmlinuz386@yahoo.com.ar wrote:
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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...
finally in the journal:
May 24 23:24:27 archiso login[184]: ROOT LOGIN ON ttyS0 May 24 23:25:27 archiso systemd[1]: Job sys-subsystem-net-devices-eth0.device/start timed out. May 24 23:25:27 archiso systemd[1]: Timed out waiting for device sys-subsystem-net-devices-eth0.device. May 24 23:25:27 archiso systemd[1]: Dependency failed for dhcpcd on eth0. May 24 23:25:27 archiso systemd[1]: Starting Network. May 24 23:25:27 archiso systemd[1]: Reached target Network. May 24 23:25:27 archiso systemd[1]: Startup finished in 2.349s (kernel)
OK but what did you call the rule?
filename? /etc/udev/rules.d/81-dhcpcd.rules
- 1.212s (initrd) + 1min 31.996s (userspace) = 1min 35.559s.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Am 25.05.2013 01:27, schrieb Gerardo Exequiel Pozzi:
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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}?
On Tue, May 28, 2013 at 03:42:19PM +0200, Thomas Bächler wrote:
Am 25.05.2013 01:27, schrieb Gerardo Exequiel Pozzi:
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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}?
Good call, this seems to work. Tested as follows on a VM:
Added a rule to force a name change:
# /etc/udev/rules.d/80-net-name-slot.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="de:ad:be:ef:00:01", KERNEL=="eth*", NAME="lan0"
And then the rule to add SYSTEMD_WANTS with Thomas's suggestion:
# /etc/udev/rules.d/81-dhcpcd.rules ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
Reboot...
# systemctl show dhcpcd@lan0 dhcpcd@lan0.service - dhcpcd on lan0 Loaded: loaded (/etc/systemd/system/dhcpcd@.service; disabled) Active: active (running) since Tue 2013-05-28 14:41:26 UTC; 2min 45s ago ....
# ip -4 a s lan0 2: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 10.0.2.138/24 brd 10.0.2.255 scope global lan0 valid_lft forever preferred_lft forever
On Tue, May 28, 2013 at 10:44:56AM -0400, Dave Reisner wrote: [...]
ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
I wonder if it would be better to += instead of just = . See [1]
[1]: http://lists.freedesktop.org/archives/systemd-devel/2012-November/007448.htm...
Cheers,
On Tue, May 28, 2013 at 06:47:29PM +0200, pancho horrillo wrote:
On Tue, May 28, 2013 at 10:44:56AM -0400, Dave Reisner wrote: [...]
ACTION=="add", SUBSYSTEM=="net", ENV{SYSTEMD_WANTS}="dhcpcd@$name.service"
I wonder if it would be better to += instead of just = . See [1]
Cheers,
-- pancho horrillo
In general, yes. We're dealing with a tightly controlled environment on the liveCD, so it shouldn't make a difference in practice.
d
On 05/28/2013 10:42 AM, Thomas Bächler wrote:
Am 25.05.2013 01:27, schrieb Gerardo Exequiel Pozzi:
On 05/24/2013 11:27 AM, Dave Reisner wrote:
On Fri, May 24, 2013 at 11:04:24AM -0300, Gerardo Exequiel Pozzi wrote:
Hello
I am planing to do a new release[#1] this weekend. Since we are using dhcpcd.service (dhcp for all net-if) and is racy, sometimes net-if rename work and others no. So I think can be a good idea to not rename at all.
Opinions?
Thanks.
[#1] Includes the change to move mkarchiso to /usr/bin.
Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
I tend to think this will make for a lousy user experience given that interface names will potentially change on the first boot of the newly installed system. Not really in favor of this.
Proposal: stop using dhcpcd.service, replace with a udev rule that launches instances of dhcpcd@.service 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}?
Perfect! Works great :)
Thanks.
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 dhcpcd@.service 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?
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 dhcpcd@.service 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
arch-releng@lists.archlinux.org