/etc/hosts file wiping edits after suspending or rebooting












0















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









share|improve this question

























  • 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 at 3: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 at 3:49











  • @Terrance, Added the output of that to the OP

    – Hamish W
    Jan 20 at 6: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 at 6: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 at 22:35
















0















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









share|improve this question

























  • 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 at 3: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 at 3:49











  • @Terrance, Added the output of that to the OP

    – Hamish W
    Jan 20 at 6: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 at 6: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 at 22:35














0












0








0








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









share|improve this question
















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






networking hosts






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 20 at 6:37







Hamish W

















asked Jan 20 at 2:07









Hamish WHamish W

379




379













  • 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 at 3: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 at 3:49











  • @Terrance, Added the output of that to the OP

    – Hamish W
    Jan 20 at 6: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 at 6: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 at 22:35



















  • 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 at 3: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 at 3:49











  • @Terrance, Added the output of that to the OP

    – Hamish W
    Jan 20 at 6: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 at 6: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 at 22:35

















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 at 3:41







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 at 3: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 at 3:49





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 at 3:49













@Terrance, Added the output of that to the OP

– Hamish W
Jan 20 at 6:37





@Terrance, Added the output of that to the OP

– Hamish W
Jan 20 at 6: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 at 6:44





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 at 6: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 at 22:35





@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 at 22:35










1 Answer
1






active

oldest

votes


















1














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






share|improve this answer


























  • 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 at 2:43











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1111258%2fetc-hosts-file-wiping-edits-after-suspending-or-rebooting%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














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






share|improve this answer


























  • 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 at 2:43
















1














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






share|improve this answer


























  • 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 at 2:43














1












1








1







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






share|improve this answer















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







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 20 at 2:33

























answered Jan 20 at 2:21









Sergiy KolodyazhnyySergiy Kolodyazhnyy

72.5k9151316




72.5k9151316













  • 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 at 2:43



















  • 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 at 2:43

















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 at 2:43





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 at 2:43


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1111258%2fetc-hosts-file-wiping-edits-after-suspending-or-rebooting%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Human spaceflight

Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

張江高科駅