Arch Linux

yuriks

Member

From: Brazil

Registered: 2012-06-30

Posts: 2

Website

Starting dhcpd IPv4 and IPv6 instances via systemd

Hey,

I've been toying with systemd recently, and hit a snag when getting it to work with dhcpd.

The current rc.d scripts have two scripts: dhcp4 and dhcp6, each reads commandline options to pass to dhcpd from different variables in /etc/conf.d/dhcpd

Systemd ships with similar functionality where you simlink dhcpd@.service to dhcpd@{4,6}.service to start the appropriate service. Problem is they both use the same config file (which is specified in the commandline options) then, and, afaik, config files for DHCPv4 and DHCPv6 instances are mutually incompatible.

For now I'm manually editing the service file to point to the correct config files, but would like to know if there's a more proper builtin way of fixing this. If not, then this sounds like a bug, right?

Relatedly, most network servers and daemons (like dhcpd, radvd, named, etc.) don't have an After=network.target line in their service files. Since a lot of these daemons just abort startup (or otherwise malfunction) if the interfaces they're supposed to operate on aren't initialized properly yet, this seems like it should be fixed too.

65kid

Member

From: Germany

Registered: 2011-01-26

Posts: 663

Re: Starting dhcpd IPv4 and IPv6 instances via systemd

can't really say anything about dhcpcd other than that falconindy changed this recently in git: https://github.com/falconindy/systemd-a … d3ad4be34d
not sure if this helps with your config file problem...
and instead of directly editing the service files, you should always override them instead.

Relatedly, most network servers and daemons (like dhcpd, radvd, named, etc.) don't have an After=network.target line in their service files. Since a lot of these daemons just abort startup (or otherwise malfunction) if the interfaces they're supposed to operate on aren't initialized properly yet, this seems like it should be fixed too.

network.target indicates "network is up", but the daemons shouldn't have to rely on that since they should work fine even if the network is not configured yet. The actual problem is that in some cases systemd boots so fast that the network daemons are started before the modules for the network devices are loaded. Or in other words, the interfaces don't exist yet when the daemons are started. There is a bug about this for dhcpcd: https://bugs.archlinux.org/task/30235

yuriks

Member

From: Brazil

Registered: 2012-06-30

Posts: 2

Website

Re: Starting dhcpd IPv4 and IPv6 instances via systemd

can't really say anything about dhcpcd other than that falconindy changed this recently in git: https://github.com/falconindy/systemd-a … d3ad4be34d
not sure if this helps with your config file problem...

I don't think it does, unfortunately. I left a comment there, let's hope he notices it.

and instead of directly editing the service files, you should always override them instead.

I tried doing that by the method presented there, but .including the file didn't work. Systemd gave me back an "Invalid parameter error" and no more info. I ended up copying the whole file to /etc/systemd/system and modifying it there, I didn't edit it directly in /usr/lib/systemd/system

Relatedly, most network servers and daemons (like dhcpd, radvd, named, etc.) don't have an After=network.target line in their service files. Since a lot of these daemons just abort startup (or otherwise malfunction) if the interfaces they're supposed to operate on aren't initialized properly yet, this seems like it should be fixed too.

network.target indicates "network is up", but the daemons shouldn't have to rely on that since they should work fine even if the network is not configured yet. The actual problem is that in some cases systemd boots so fast that the network daemons are started before the modules for the network devices are loaded. Or in other words, the interfaces don't exist yet when the daemons are started. There is a bug about this for dhcpcd: https://bugs.archlinux.org/task/30235

Interesting. I'll try that work around and see if helps me. (I have the same issues, random load failures.) Thanks.