/etc/hosts file wiping edits after suspending or rebooting
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
|
show 1 more comment
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
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 ofls -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 thels -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 ifnano
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 tryingsudo 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
|
show 1 more comment
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
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
networking hosts
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 ofls -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 thels -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 ifnano
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 tryingsudo 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
|
show 1 more comment
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 ofls -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 thels -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 ifnano
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 tryingsudo 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
|
show 1 more comment
1 Answer
1
active
oldest
votes
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
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 ofls -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 tryingsudo 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