Duplicate entries inside /etc/hosts

ypanier

HI

Is it normal to have duplicate entries inside /etc/host ?

Before the activation of the DNS Resolver:


2.3.4-RELEASE][ypanier@pfSense1.localdomain]/home/ypanier: cat /var/etc/hosts
127.0.0.1	localhost localhost.localdomain
::1	localhost localhost.localdomain
172.16.16.1	pfSense1.localdomain

After activated it :


[2.3.4-RELEASE][ypanier@pfSense1.localdomain]/home/ypanier: cat /var/etc/hosts
127.0.0.1	localhost localhost.localdomain
::1	localhost localhost.localdomain
172.16.16.1	pfSense1.localdomain

# dhcpleases automatically entered
172.16.24.8	nfs-server.localdomain nfs-server		# dynamic entry from dhcpd.leases
172.16.24.2	mirror-docker.localdomain mirror-docker		# dynamic entry from dhcpd.leases
172.16.16.13	private-docker.localdomain private-docker		# dynamic entry from dhcpd.leases

# dhcpleases automatically entered
172.16.24.2	mirror-docker.localdomain mirror-docker		# dynamic entry from dhcpd.leases
172.16.16.13	private-docker.localdomain private-docker		# dynamic entry from dhcpd.leases
172.16.24.8	nfs-server.localdomain nfs-server		# dynamic entry from dhcpd.leases

# dhcpleases automatically entered
172.16.24.2	mirror-docker.localdomain mirror-docker		# dynamic entry from dhcpd.leases
172.16.16.13	private-docker.localdomain private-docker		# dynamic entry from dhcpd.leases
172.16.24.8	nfs-server.localdomain nfs-server		# dynamic entry from dhcpd.leases

Sometimes it happens than the same host have an old address and the new one and cause to return the wrong DHCP IP lease.

Encounter with pfsense 2.3.3 and 2.3.4 with dhcp failover

Is there a reason / solution for this ?

Best regards,

luckman212

Happening to me too - even on the latest 2.4.0-RC builds. I looked into it, seems to be a bug with system_dhcpleases_configure() getting called too frequently, possibly overlapping. I'm trying to come up with a fix.

johnpoz

Have not seen this, but then again I do not set resolver to add dhcp leases, only the static ones. So it only adds entries for my dhcp reservations. Since all boxes that I would want/need to resolve via name would be assigned a static ip via reservation.. Things like guest clients or temp boxes that might get a dhcp normally don't need to be resolved via dns..

This would be a simple work around to your issue until they correct the problem (if there is one) etc..

luckman212

Thx John, yeah it might not be a very common option. Last time I checked it was especially bad to have enabled when using Resolver (unbound) – it forces a full stop/start of the service for every DHCP lease update (yuck). Forwarder (dnsmasq) handles that better. Either way, bug's a bug - hopefully I can find a quick fix for this.

jimp

It doesn't really matter much in /etc/hosts. Unbound (Resolver) doesn't read /etc/hosts, that would only be used by the firewall itself, and it wouldn't care much about the duplicates.

luckman212

Does get used by dnsmasq though, and some people are using that. I for one had to ditch Unbound because it was causing too many problems for me with stop/start causing the GUI to hang. I know some work's been done on that for 2.4 so I may give it another try but dnsmasq has smoothed all that out for me.

luckman212

@ypanier: would you mind testing my patch for this issue? Use System Patches and install commit f0f56a7f4ea9b6636102c380d2d210983a08c996
I tested this on 2.4.0.r.20170925.1424 and it does work for me.

edit: I submitted a PR#3832 to get more feedback.

(boring part below) a bit more info on how I arrived at this patch

• when dhcpleases is sent a signal, anything less than TERM(15) causes it to not delete the auto-added entries from /etc/hosts
• the code in dhcpleases.c@L560 that handles the HUP signal seems bugged (when could hostssize ever be <0, and if it's >0 then it seems like this would just reset the "deletion pointer" so that the dynamically added entries would now never get deleted when the SIGTERM eventually comes – but I can't be 100% sure so best to just never send this signal and just always kill and respawn
• replacing the sigkillbypid() calls with /bin/pkill -x appears more reliable, since there seem to be some conditions where >1 copy of dhcpleases is running yet only 1 has a var/run/pidfile
• the if (is_process_running("dhcpleases")) { … } ~L630 in system.inc appears useless; whether dhcpleases running or not, it needs to be killed & respawned - so let's just go ahead and do that

This may not all be correct but it is the best I could do w/ my limited research and does fix the issue for me