1

18.04 with latest updates.

I am trying to modify my /etc/hosts file so I can access my local server via its hostname.
I make the change with sudo nano /etc/hosts, and it sticks fine for the current session. However, after rebooting my system or suspending it, the file reverts itself back to the state it was in before I edited it.
I have attempted to edit using both the terminal in a graphical session as well as from a tty prompt on a fresh boot with no avail.
This has only started happening since a new router was installed in my homes network, however I cannot see why that would cause this issue. 

$ ls -al /etc/hosts   
-rw-r--r-- 1 root root 254 Jan 20 17:03 /etc/hosts
Hamish W
  • 303
  • You might have something else changing it if it is not staying. Are you changing the /etc/hosts file as sudo? /etc/hosts is not a link file nor is it controlled by any daemons that I am aware of, so there shouldn't be any reason why it is changing between reboots. What is the output of ls -al /etc/hosts? – Terrance Jan 20 '19 at 03:41
  • Sorry, forget about the sudo part, I see it in your question. I am still very curious what the ls -al /etc/hosts outputs. It should be a standalone file with a 644 permissions owned by root:root. – Terrance Jan 20 '19 at 03:49
  • @Terrance, Added the output of that to the OP – Hamish W Jan 20 '19 at 06:37
  • Hmmmmm, that is so odd. I wonder if nano might be creating a temp file that is not getting erased before reboot, then when a reboot happens, it takes the tmp file and overrides the one that was just changed? I don't know for sure, but can you try adding a line to the bottom of your hosts file by trying sudo bash -c 'echo "127.0.1.1 $(hostname)" >> /etc/hosts' from a terminal window then reboot and see if that sticks? – Terrance Jan 21 '19 at 06:44
  • @Terrance, I figured it out. Turns out there is no issue, I am just stupid. I just remembered that I have a script that changes the host file depending on if I am at home or out so I can access my server with either scenario. The new router means a new SSID which means that script is broken. Derp. Thanks for the help anyway! – Hamish W Jan 21 '19 at 22:35
  • Glad that you figured it out! =) – Terrance Jan 21 '19 at 22:44

1 Answers1

0

The file is overwritten by systemd-resolved.service, among other files:

systemd-resolved synthesizes DNS resource records (RRs) for the following cases:

  • The local, configured hostname is resolved to all locally configured IP addresses ordered by their scope, or — if none are configured — the IPv4 address 127.0.0.2 (which is on the local loopback) and the IPv6 address ::1 (which is the local host).

  • The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

  • The hostname "_gateway" is resolved to all current default routing gateway addresses, ordered by their metric. This assigns a stable hostname to the current gateway, useful for referencing it independently of the current network configuration state.

  • The mappings defined in /etc/hosts are resolved to their configured addresses and back, but they will not affect lookups for non-address types (like MX).

According to documentation for /etc/systemd/resolved.conf and the related post, you can edit /etc/systemd/resolved.conf to have specific domain resolved by your local DNS sever (on Ubuntu you have dnsmasq, example), or add ReadEtcHosts= to let the service actually use the file.

You can also disable the service. See How to disable systemd-resolved in Ubuntu?

According to a Fedora forum thread the issue could also relate to Network Manager service. For Ubuntu servers, cloud-init could also be the cause of the issue according to the bug report on launchpad

Sergiy Kolodyazhnyy
  • 105,154
  • 20
  • 279
  • 497
  • Thanks for the help. I disabled systemd-resolved per the instructions however that doesnt fix the issue, the hosts file is still being reset.
    As for that bug you linked, I dont think that is what is going on here as I am pointing to another IP on my LAN, not using 127.0.0.1     – Hamish W Jan 20 '19 at 02:43