| Summary: | net-misc/dhcpcd per interface systemd unit file | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Łukasz Stelmach <stlman> |
| Component: | [OLD] Core system | Assignee: | William Hubbs <williamh> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | base-system, systemd |
| Priority: | Normal | ||
| Version: | 2008.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Systemd unit file for a single interface.
Systemd unit file for a single interface, more synchronous version. |
||
|
Description
Łukasz Stelmach
2012-09-26 21:05:52 UTC
Created attachment 325070 [details]
Systemd unit file for a single interface.
Systemd team, can I install the attached service file along side the other one we have, or should I put it on a use flag so that you get one or the other? (In reply to comment #0) > Please find attached an alternative systemd unit file for dhcpcd which > spawns dhcpcd for selected interface only. What is the use case? Are you aware that you can select interfaces in dhcpcd.conf? As for Comment #2, yes it can be installed as /usr/lib/systemd/system/dhcpcd@.service and that's all. If one wants to use it one invokes systemctl enable dhcpcd@eth0.service To answer Comment #3 (in reversed order): No, I haven't been aware of that fact. In which case the answer about usecase would not be as simple as I wish. But... of course if you use dhcpcd@.service you can easily enable and disable dhcpcd for each interface you want with just a single systemctl command. I admit that spawning a process for each interface might be considered by some a waste but I only suggest giving users an option. > To answer Comment #3 (in reversed order):
>
> No, I haven't been aware of that fact. In which case the answer about
> usecase would not be as simple as I wish. But... of course if you use
> dhcpcd@.service you can easily enable and disable dhcpcd for each interface
> you want with just a single systemctl command. I admit that spawning a
> process for each interface might be considered by some a waste but I only
> suggest giving users an option.
We will be happy to give users an option if they need it. Giving duplicate solutions leads only to confusion on users who don't know which one they should use.
OK. One last question for I've got no hardware to check myself. Is dhcpcd capable of managing hotplugged interfaces, ones that weren't present when it was launched? Created attachment 325572 [details]
Systemd unit file for a single interface, more synchronous version.
I found a use case. dhcpcd when started without --nobackground fulfils systemd definition of a forking daemon (systemd.service(5)).
If set to forking it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels set up. The child continues to run as the
main daemon process.
dhcpcd exits *after* the network interface gets its address. This allows for a more controlled situation where we can be sure that when the network.target is reached the network communication has been established.
However systemd is about fast bootup, it is not about a messy one.
(In reply to comment #7) > Created attachment 325572 [details] > Systemd unit file for a single interface, more synchronous version. > > I found a use case. dhcpcd when started without --nobackground fulfils > systemd definition of a forking daemon (systemd.service(5)). > > If set to forking it is expected that the process configured with > ExecStart= will call fork() as part of its start-up. The parent > process is expected to exit when start-up is complete and all > communication channels set up. The child continues to run as the > main daemon process. > > dhcpcd exits *after* the network interface gets its address. This allows for > a more controlled situation where we can be sure that when the > network.target is reached the network communication has been established. > > However systemd is about fast bootup, it is not about a messy one. Does anyone want to use that practically? (In reply to comment #7) > Created attachment 325572 [details] > Systemd unit file for a single interface, more synchronous version. > > I found a use case. dhcpcd when started without --nobackground fulfils > systemd definition of a forking daemon (systemd.service(5)). > > If set to forking it is expected that the process configured with > ExecStart= will call fork() as part of its start-up. The parent > process is expected to exit when start-up is complete and all > communication channels set up. The child continues to run as the > main daemon process. > > dhcpcd exits *after* the network interface gets its address. This allows for > a more controlled situation where we can be sure that when the > network.target is reached the network communication has been established. By the way: 1. this isn't really interface-specific. Without any interfaces specified, it works the same; 2. I'd personally prefer even implementing SYSTEMD_READY than getting into this forking thing... (In reply to comment #9) > 1. this isn't really interface-specific. Without any interfaces specified, > it works the same; What does it mean when dhcpcd started without interface names as command line arguments forks on a system with four interfaces? Does it fork (I am trying to figure it out now) when the first gets its address or when all of them do? It looks like the former. How would you set systemd+dhcpcd not to reach network.target until (this will be evil) wlan0 and eth1 have their IP addresses from DHCP when eht0 is configured statically and wlan1 is not configured at all? > 2. I'd personally prefer even implementing SYSTEMD_READY than getting into > this forking thing... I am afraid I don't know how would you like to do it. If you set SYSTEMD_READY to 0 then systemd would treat the interface as if it didn't exist at all and wouldn't look at SYSTEMD_WANTS (think: SYSTEMD_WANTS="dhcp@%k.service"). Starting dhcpcd from udev and making them talk to each other to finally set SYSTEMD_READY to 1 doesn't seem to be the right way to do it. |
