After modifying /etc/hosts, which service(s) need(s) to be restarted for the change to take effect?
- 69,223
- 56
- 216
- 327
- 2,337
- 3
- 19
- 23
-
17For anyone coming back here through random web search... Obviously don't run `sudo ifconfig eth0 down` if you are on a SSH client for similar. – OskyEdz Jan 04 '17 at 06:01
-
1@OskyEdzSnakehult unless you run both in one line, separated by `&&`, inside tmux/screen/etc. so that the command completes even though you get disconnected temporarily. – Walf Oct 02 '18 at 03:10
9 Answers
You don't need to restart any services.
When tested on a 14.04 server installation, the changes were reflected immediately.
The only service that I think could be related is 'networking', but it's unnecessary to restart it.
- 19,653
- 18
- 73
- 128
-
-
1// , Incidentally, this is also true of Mac OS X (10.12.4 (16E195)). – Nathan Basanese May 01 '17 at 20:34
-
I didn't have to restart any services, but had to reboot my machine for it to work – Gayan Weerakutti May 27 '17 at 07:42
-
2rebooting is, technically, restarting _every_ service. And it shouldn't be necessary... though, note that some applications (eg., firefox) may cache this data and the _applications_ need to be restarted. – michael Nov 02 '17 at 05:31
-
6
-
2
You can try: (Disclaimer: Don't run it if you're connected via SSH)
sudo ifconfig eth0 down
sudo ifconfig eth0 up
(substitute eth0 with your network card)
but Arronical is right in theory: You don't need it.
- 103
- 4
- 179
- 7
-
7This is what I tend to do after any network changes, I normally put `&&` between the two commands to make it a one-liner. – Arronical Aug 26 '15 at 13:31
-
27
-
4if connected via remote ssh, then a reboot might be just as (un)safe as a manual network stop/start (because, of course, after turning off networking, you're disconnected & can't turn it back on -- or even reboot!). However, to do a `ifconfig` down + up, then use something like gnu screen (or tmux), and run both commands at once via `ifconfig up && ifconfig down` or putting them into a two-line shell script and running that. Then reconnect to your gnu screen/tmux session afterwards -- if all goes well. – michael Nov 02 '17 at 05:37
If you use dnsmasq (is set by default), then do following:
$ pkill -HUP dnsmasq
- 185
- 1
- 5
-
Thank you. This was the only one that worked for me. The ping worked, but none of the browsers could reach the site. – makkasi Dec 11 '20 at 10:54
-
1
-
When it receives a SIGHUP, dnsmasq clears its cache and then re-loads /etc/hosts – Gustav Feb 03 '23 at 13:13
Theoretically, changes to the /etc/hosts file take effect immediately.
But, if you get old hostname after this
$ hostname
then, either reboot or restart your network connection... that should show you the right hostname.
- 69,223
- 56
- 216
- 327
- 759
- 6
- 14
For the most part etc/hosts changes should be recognized immediately. If you add a new entry then ping it by name on the machine hosting the etc/hosts file it will most likely ping, that means the etc/hosts update has been recognized by DNS. On a pihole system if you restart the DNS resolver it will pick up the newly-added/edited etc/hosts entries. Most likely it's a function of whatever program is trying to utilize the hosts entries, did it read the current stuff or did it read just at boot time, or like pihole, will it reread by restarting a simple internal function?
- 41
- 2
You need to restart systemd-hostnamed service which is a system service that may be used to change the system's hostname and related machine metadata from user programs.
/bin/systemctl restart systemd-hostnamed
- 141
- 1
Actually I noticed that postfix might benefit of a restart to include the new hosts in its local host file version that is available here /var/spool/postfix/etc/ (ubuntu 16.04)
- 246
- 2
- 5
You probably don't need to restart anything, unless there is a temporary cache of the DNS somewhere. To restart networking and clear the DNS cache on Debian and Ubuntu:
sudo /etc/init.d/networking restart
- 201
- 1
- 5
I kept getting an error, and google took me to this question. I thought I needed to restart some service, but actually I found it was my fault:
$ ping remote_hostname
ping: unknown host remote_hostname
The reason why hosts wasn't recognising a new entry was a typo in the IP address:
##.2480.##.## remote_hostname
- 11
- 1
-
or, uh, not that I would ever do this myself of course, but just sayin' you might also end up on this page if you put the hostname first and then the IP address – joseph_morris Mar 03 '23 at 16:49