Arch Linux User Repository

Hey guys, Found a bug with the .service file provided: Oct 21 11:33:32 core.hq systemd[1]: network.target: Found ordering cycle on network.target/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager-wait-online.service/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager.service/verify-active Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on dhcp6c@wan0.service/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on network.target/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Breaking ordering cycle by deleting job NetworkManager-wait-online.service/start Oct 21 11:33:32 core.hq systemd[1]: NetworkManager-wait-online.service: Job NetworkManager-wait-online.service/start deleted to break ordering cycle starting with network.target Oct 21 11:33:32 core.hq systemd[1]: network.target: Found ordering cycle on network.target/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on NetworkManager.service/verify-active Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on dhcp6c@wan0.service/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Found dependency on network.target/start Oct 21 11:33:32 core.hq systemd[1]: network.target: Breaking ordering cycle by deleting job NetworkManager.service/verify-active Oct 21 11:33:32 core.hq systemd[1]: NetworkManager.service: Job NetworkManager.service/verify-active deleted to break ordering cycle starting with network.target/start It seems impossible to require network.target and complete before other services like dnsmasq which also require network.target. I use netctl for network, so I depend on my wide area interface coming up, patch for dhcp6c@.service: [Unit] Description=WIDE-DHCPv6 Client on interface %I -After=netctl@%i.service +After=network.target +Requires=network.target Before=dnsmasq.service Before=NetworkManager.service Documentation=man:dhcp6c(8) man:dhcp6c.conf(5) This will be different for other network managers, not sure if there is a generic wide area network target, but that'd be better.

Fixed, thank you!

The latest version of pacman has different "conflicting file" logic and complains with: error: failed to commit transaction (conflicting files) wide-dhcpv6: /usr/sbin exists in filesystem Errors occurred, no packages were upgraded. This can be resolved by changes to the PKGBUILD. In the build() function, adding: ... --sysconfdir=/etc/wide-dhcpv6 \ --sbindir=/usr/bin and in the package() function, changing: mkdir -p "${pkgdir}/usr/sbin" to: mkdir -p "${pkgdir}/usr/bin"

I've noticed that systemd-networkd can interfere with dhcp6c, the WIDE DHCPv6 client daemon. Currently, 2015 January, in systemd-networkd, the DHCPv6 client seems to not be working itself, despite what is implied by man 5 systemd.network, but still, if a "network" file is configured with: [Network] DHCP=both or [Network] DHCP=v6 systemd-networkd will bind the DHCPv6 UDP port, number 546. If then dhcpv6c is started, to fetch just a Non-temporary Address, it will fail to bind to the interface. Maybe this is obvious, in retrospect. But remember to set: [Network] DHCP=v4 in any network files, if you are using systemd-networkd and dhcpv6c together. Also, I noticed that the wpa_supplicant systemd service file uses: [Unit] After=sys-subsystem-net-devices-%i.device and it seems like a useful thing to add to the dhcp6c systemd service file as well, especially for when the device is a wireless device. Of course, make an appropriate substitution for "%i", if necessary, depending upon whether the service file is a "template" file, or instead, references an Environment File.

I don't know how common it is to have multiple (full disclosure: I don't need it) dhcpv6 interfaces, but I see no reason to limit AUR users wit this. I'm following the spirit of netctl and friends that use instances per interface. The dual systemd service file will work, but seems distracting. This AUR package doesn't need to cater to me, but I think my requests are more generic and is why I brought them up -- to hopefully improve the usefulness for everyone. @Foucault the revised conf files make sense as well, but we need to be careful of all the systems that will break when it changes. That's how my original frustration came about. :)

Well that's an (unexpectedly) heated discussion! What could be done is to provide both a dhcp6c@.service and dhcp6c.service file (that's what the dhcpcd package does for example). Then everyone is happy although at the moment the only advantage that %I provides is the ability to spawn multiple instances of the program for many interfaces. Is it *that* common though (honest question)? I would not like to change the environment variable names though, since in my opinion more descriptive variables are better (within reasonable limits, of course), as in "self-documenting". The conf file name choice was a bit poor indeed and it would be better to change it to something more sane (/etc/conf.d/dhcp6c.conf or something). Same thing goes with the sysconfdir, which is named after the program. It is reasonable to use "wide-dhcpv6" as the dir name since this is how the program is named and it would help to avoid confusion with other dhcp programs (ISC, dhcpcd, whatever). "dhcpv6" is a bit vague and I am not willing to change that (FYIW, debian also uses wide-dhcpv6).

Short response: The "wan0" is an example. The average Arch Linux user is more then competent enough to substitute the appropriate interface in there. If they want to use links, fine, the name of the interface and how it comes to exist is irrelevant. The point is that my solution supports multiple network interfaces, I will avoid using wan[0..] as it appears distracting. Remembering interfaces is not hard. Bash and zsh will even tab-complete them `systemctl status dhcpv6<tab-tab>` if the right packages are installed and the service(s) is/are enabled. Also `systemctl list-units dhcp6\*` is easy enough for the once per year AUR breakage that users may need to remember their interfaces. Very rarely do I need to manage wide-dhcpv6 except after my last update where this startpd.conf file broke all my IPv6 systems. The environments file will always break the ability to have multiple interfaces running dhcpv6 as I've explained before because it assumes only 2 are possible. Again, the average Arch user is a power-user and I suggest a solution that doesn't restrict their ability to use a service. Occam's razor applies here and selects the simpler config file that's actually more powerful. And I don't mean to nit-pick your service file about things like %I and the PID file other then to point them out so we as a community can clean them up and resolve them. Anyone else have comments or opinions?

I'm including some man page references for the benefit of anyone following this thread, and not to insinuate that you had not read them. :) The systemd documentation is a bit "spread-out". I appreciate you examining the ".service" file. > Judging from your comments it's just to prevent you from having to remember > your systemd instances. Yes, exactly. You may scoff, but when configuring different machines, or changing the hardware on a machine, or swapping interfaces on a machine, remembering the correct unique interface identifier can be error prone. It is bad enough, when changing an interface name, that multiple configuration files must be modified - for systemd-networkd, dnsmasq, dhcp6c, and whatever else. Another alternate approach is to modify the interface names to something generic only once, using "/etc/systemd/network/<interface>.link" files, and then to use the generic names everywhere else. But then, that special ".link" file must be written first. > Unfortunately this goes in the face of systemd and your solution doesn't > scale to more then one dhpc6 server and one dhcp6 client. What if I have > multiple interfaces? Systemd's instances will handle "dhcp6c@wan0" > "dhcp6c@wan1" without any problems and with less work. 1) Arch uses unique identifier names for interfaces, not "wan0", and so on. 2) "goes in the face of systemd" is unfair, since systemd also supports "EnvironmentFile=", as well as "Environment=", as described at "man 5 systemd.exec". Rather, it is a matter of using an "Environment File" approach or a "Template File" approach for the ".service" file, at "man 5 systemd.unit". Or, using interface re-naming, at "man 5 systemd.link", or using unique ".service" files in "/etc/systemd/system/". "systemd" supports all of these approaches. 3) Using special ".link" files and the generic "wan0" and "wan1" may be more elegant, as the WAN interface changes back and forth, for instance, between the hardwired interface and the wireless interface, but then "something" will have to issue a sequence of explicit "systemctl" commands to enable, disable, start, and stop the changing WAN interfaces, and also, to modify all the other network configuration files to reference the correct "wan0" or "wan1", including the dhcp6c configuration file, and then, to "restart" these other network daemons. This dynamic networking scenario is something much more complex than a simple static-interface wide-dhcpv6 install. Admittedly, the Environment File approach, by itself, does not solve this dynamic configuration problem. Neither can NetworkManager or systemd-networkd yet provide Prefix Delegation for dynamic interfaces. 4) Alternatively, using special ".link" files and a single generic "wan0", which was then dynamically associated with the active WAN interface, would still require modifying every other configuration file with network interface references, to reference "wan0" explicitly. If and when systemd-networkd gains the ability to handle dynamic network configuration, then a generic "wan0" approach would have an advantage. By then, systemd-networkd presumably would also automatically issue a "restart" to all the active network daemons, after changing the active "wan0" WAN interface. 5) The current dhcp6c has its own problems, in that, even though the man page shows "interface" as a required command line parameter, in actuality, dhcp6c will "glom" all of the active interfaces. And, even when the Template File approach to the ".service" file is used, the dhcp6c configuration file at "/etc/wide-dhcpv6/dhcp6c.conf" _has_ to reference the correct WAN interface, to request a Non-temporary Address and a Prefix Delegation, and the correct LAN interface to apply the correct Site-Level Aggregator address. So, issuing a "sudo systemctl start dhcp6c@<some_WAN_interface>" along with a "dhcp6c.conf" file specifying "some_different_WAN_interface", is going to cause problems. I did try running "dhcp6c" without any interface argument. It fails. I even tried running "dhcp6c" with a bogus interface argument. That fails too. But then, it is also silly to require an interface argument to "dhcp6c", since the config file _has_ to match the WAN interface and the LAN interface. _There's_ a project opportunity for someone, cleaning-up wide-dhcpv6 a bit. 6) Accidentally starting dhcp6c on the "wrong" interface is going to be a mostly "silent fail", since dhcp6c will start just fine, but still not do the right thing. > Furthermore, the presence of "%I" in the Description (at the time of writing) > tells systemd to expect an instance, but the lack of "@<instance name>" for > the service confused me until I read the comments on this AUR to understand > the history. In my defense, that was not me. ;) The reference should be "${WAN}" or "${DHCP6C_WAN}", whatever, when using an Environment File approach, and "%I" and "%i" when using a Template File approach, described at "man 5 systemd.unit". Yes, the "Description=" entry should be corrected. > 2. Why is a pid file being written if nobody is using it? In a post- SYSVINIT > era, these are just noise. > 3. Exec stop is over verbose, systemd would send the TERM signal correctly > anyways Ok. I was not sure if systemd needed the pid file to track "$MAINPID". I was following the example at "man 5 systemd.service". But, since dhcp6c is made to run with "-f", non-forking, I suppose that tracking the PID is not a problem for systemd. In any case, dhcp6c is _still_ going to write "/var/run/dhcp6c.pid", by default, and the dhcp6c command line switch merely illuminates this default. You could write a patch for dhcp6c, I suppose, to stop it writing a PID file. ;) The "ExecStop" entry seems to be the default also. Yes, the "[Service]" section can be simplified. > Then of course the service name is "dhcp6c@wan0" and everyone is happy The literal command "sudo systemctl start dhcp6c@wan0" will fail, since there will not be a "wan0" interface, without writing a special ".link" file, which would also require modifying all other configuration files referencing the WAN interface, and restarting all other network daemons when "wan0" references a changing WAN interface. This is mostly a matter of personal preference, though, using a Template File approach for the ".service" file and remembering the unique identifier names or using an Environment File approach for the ".service" file and writing a config file with "WAN=<interface>", or writing special ".link" files to create generic interface names for the Template File approach, or just writing a unique ".service" file for each running dhcp6c. I believe that explicitly writing and storing "WAN=<interface>" in a config file, to match the "dhcp6c.conf" file, and assuming there is only one WAN interface, will be simpler and less error prone than memorizing which unique interface identifier goes where for every interface on every machine managed - or writing special ".link" files or unique ".service" files. Obviously, the ".service" file can be customized, after an install. Months later, I think remembering "dhcp6c", rather than "dhcp6c@<what_interface_was_that_anyway>", is going to be easier. On a tangent, I would prefer to have "--sysconfdir=/etc/dhcpv6", instead of "--sysconfdir=/etc/wide-dhcpv6". The name is more succinct, and there is no name clash, with all the other "dhcp's". James