sed is a very powerful tool. Small than awk and grep and much more powerful. Some would also say it’s harder to use, but I like it :)
Whilst putting a mini resolvconf into dhcpcd, I use very similar code to what I already had. But, I ran into a wall- dhcpcd needs to work when /usr is not mounted as it may be network mounted later. On Gentoo and most Linux distros, sed is found in /bin.
/etc/resolv.conf is a single file that is often stamped on by many different applications. One example of this is dhcpcd running on multiple interfaces. openresolv is a resolvconf implementation to help ahem resolve this by taking resolv.confs from these applications to make a single sane file.dhcpcd has always supported resolvconf when available - but what if it’s not? dhcpcd restores the last saved resolv.conf when it fails/exits to try and make things work, but it’s not exactly optimal as the order interfaces go down may not be the same order as when they come up.
All DHCP clients like to stamp their view on configuration files. After all, that is part of their job :) However, many people also have their own settings in the same configuration file. Most people don’t notice dhcpcd stamping on these files, but when they do they normally just turn that feature off.
The main culprit here is ntp.conf, as it can have quite a complex setup and dhcpcd has always imposed it’s own world view on it.
So I’ve finally found out why the dhcpcd-4.0.0-rc series sometimes wedges itself - select and poll do not always timeout on time. If they return 0, then can return slightly early and the real time left is very small. This is likely a kernel timer resolution issue, something that won’t be fixed easily, quickly or ever. Now, for fully passing IPv4LL compliance AND being DHCP re-transmission compliant AND timing out to the userland correctly we introduced expiry timers in dhcpcd-4.
Hmmmm, all my blogs appear to be about dhcpcd these days. No bad thing though eh? Anyway, if you’ve been using dhcpcd-4.0.0-rc1 or rc2, you should update to rc3 as it fixes an issue with infinite leases and a potential issue with lease time overflowing time_t (as uint32_t is greater than time_t on 32-bit platforms). To get around this issue, we simply treat any unusable leases as infinite. This shouldn’t be a problem as we base all our times around a monotonic clock instead of the actual time which means that when dhcpcd restarts you can handle leases of up to 67 years ahead.
Roy's Blog