Duplicate entries inside /etc/hosts



  • 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,



  • 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.


  • LAYER 8 Global Moderator

    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..



  • 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.


  • Rebel Alliance Developer Netgate

    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.



  • 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.



  • @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


Log in to reply