9

I was playing with the /etc/hosts file on my Raspbian installation and outcommented the "127.0.1.1 raspberry" line. I know that the host file is basically there to facilitate address look up. However, by doing this, it started giving me following error whenever I try to run a command with sudo.

unable to resolve host raspberrypi

Also, I noticed an abnormal behavior. For example, running df -h when it's been outcommented. It shows my rootfs being full.

pi@raspberrypi ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  6.9G     0 100% /
devtmpfs        364M     0  364M   0% /dev
tmpfs            74M  244K   74M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           148M     0  148M   0% /run/shm
/dev/mmcblk0p1   56M   20M   37M  35% /boot
tmpfs           148M     0  148M   0% /tm

While uncommenting it and bringing it back to normal, it makes it normal as follows:

pi@raspberrypi ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.2G  3.3G  3.6G  49% /
devtmpfs        364M     0  364M   0% /dev
tmpfs            74M  244K   74M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           148M     0  148M   0% /run/shm
/dev/mmcblk0p1   56M   20M   37M  35% /boot
tmpfs           148M     0  148M   0% /tmp

I followed a couple of links, like this and this, but I couldn't figure out why it's happening and how removing a host affects applications in general. What is the reason?

Community
  • 1
dhruvvyas90
  • 2,853
  • 3
  • 19
  • 32

3 Answers3

10

Using 127.0.1.1 in addition to 127.0.0.1 is just a Debian convention; here's the justification. It is not a bad thing. These two addresses amount to the same thing anyway; a more widespread methodology would be to use an alias:

127.0.0.1 localhost.localdomain raspberry.pi

But using a distinct address is perhaps a better practice since it would allow you to distinguish one from the other in certain situations.

The purpose of /etc/hosts is described in man 5 hosts.

whenever I try to run a command with sudo

For an explanation of why that is, see here, which I'll briefly quote:

The /etc/sudoers file is designed to be able to be distributed among multiple servers. In order to accomplish this, each permission in the file has a host portion. [...] In order for sudo to know whether this rule should be applied, it needs to lookup the host it is running on. It uses a call that relies on the /etc/hosts being correct, which is why it fails if it is not right.

As for

how removing host affects applications in general

Applications use networking mechanisms to communicate with each other, and if these are IP based they may use localhost to do this. The loopback interface is conceptual and implemented in the kernel (i.e., it doesn't involve actual network hardware). I don't think that explains your df issue, but if it is consistently reproducible (I could not get the output of df to change by commenting everything in /etc/hosts out) then obviously there's some connection.

Community
  • 1
goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • 1
    Upvote. Totally agree. One thing to remember (if you are used to working with Windows hosts files), is that Raspbian does not automatically take care of the local system's hosts entry so it needs to be explicit. – SDsolar May 02 '17 at 21:11
  • Funny thing is that there are software stacks that when you try to make a server listen for a given hostname, it ends up binding to that 127.0.1.1 instead of the actual network IP precisely due to that hostname entry. The debian docs even recommend changing the entry to the actual IP when you have a permanent IP (I am guessing due to this), but mentions nothing in other cases. – eglasius Jan 12 '23 at 16:49
  • In general you should bind to "the any/all address" so you do not end up just listening on the loopback. If there are external interfaces you don't want to really accept from, block the port using firewall rules. That said, if you have a legit hostname on an external network and you really want to listen explicitly for that, you should be able to rely on DNS to get the IP correct (if not, it isn't really a legit hostname and external clients won't be able to connect using it anyway). Ie., you don't need to list the hostname in /etc/hosts at all (but you could put it in /etc/hostname). – goldilocks Jan 12 '23 at 17:22
3

The /etc/hosts file is actually there to make DNS lookup unnecessary for domains/hostnames.

e.g. if you add an entry to your /etc/hosts file of 

127.0.0.1     www.google.com

the computer will not perform a DNS lookup for google.com, it will take you to the IP address in the hosts file entry.

127.0.0.1 is the internal IP address of your computer, so by removing the "127.0.0.1 raspberrypi" entry from it, your computer is trying to perform a DNS lookup on the domain "raspberrypi". This domain does not exist, hence the error message.

Read What is the use of /etc/hosts? for more.

Community
  • 1
Dbmeister
  • 39
  • 2
  • 1
    But how does it affect while I run any program on shell ? and of course why ? – dhruvvyas90 Jun 28 '15 at 10:12
  • This only answers the purpose of /etc/hosts but not the reason for the 100% on / df -h issue. – Greenonline Jun 28 '15 at 19:03
  • You can also add a no-fly list in your hosts file to prevent you from going to annoying sites like Forbes.com or washingtonpost.com - Just put in an entry for it and redirect it somewhere you like, such as 127.0.0.1 or, my favorite, the address for Google. – SDsolar May 02 '17 at 21:13
  • If your Rpi has static IP addresses, it never hurts to include them in the hosts file. But there also is no reason for it if your hostname is set correctly. since you are unlikely to remote into your own system. – SDsolar May 02 '17 at 21:15
2

@goldilocks answer is completely correct AFAIK; this answer is posted to hopefully augment that answer with some additional information:

The best explanation and guidance I've seen for /etc/hosts, and the address 127.0.1.1 is in the Debian Reference, Chapter 5 - Network Reference,Para 5.1.1 hostname resolution. It contains some specific guidance on the /etc/hosts file including the following:

  1. The host_name matches the hostname defined in the "/etc/hostname".

    This may be misleading. As I read this, there's an implication that the entry in /etc/hostname updates the entry in /etc/hosts. However there is no such automatic update feature, nor does it happen even after reboot - at least on my RPis.

    Rather, read this as an instruction: you (the administrator) must edit the 127.0.1.1 entry in /etc/hosts to "match" the /etc/hostname entry.

    The take-away should be that these two hostname entries should match - under most normal circumstances. You can easily verify that there is a match:

    $ hostnamectl | grep hostname && cat /etc/hosts | grep '127.0.1.1'  
Static hostname: raspberrypi4b  
Transient hostname: raspberrypi4bxyz  
127.0.1.1    raspberrypi4b  
# NOTE the appearance of a 'Transient hostname' implies 
# the old name is being cached; reboot will flush it out

  2. For a system with a permanent IP address, that permanent IP address should be used here instead of 127.0.1.1.

    Users (mis-informed ones mostly) of the static <value> option in /etc/dhcpcd.conf should take note.

  3. The package resolvconf (typically installed in /sbin) populates the file /etc/resolv.conf. This file will contain a domain name if you've defined one in your router/gateway, and the address of your internal nameserver - typically your router/gateway.

  4. The file /etc/nsswitch.conf should contain a line like the following to enable zero conf networking, and resolution of host names ending in .local:

    hosts: files mdns4_minimal [NOTFOUND=return] dns

  5. Vintage Windows users may rejoice in the explanation provided for integrating systems that still use NetBIOS!

And so informed, it should be clear that deleting the line with 127.0.1.1 in your /etc/hosts <hostname from /etc/hostname> file will cripple mDNS which is (by default) how at least your RPi systems find each other, and make themselves find-able from other mDNS/zero-conf systems.

This "bookmark-worthy" document should be retained for future reference, especially since the RPi Organization has announced their intention to deprecate some of the "common" Linux documentation currently contained in their repo.

Wrt the other anomalies noted in the question:

  1. sudo: unable to resolve host <xxxxx>: Name or service not known

I can't add a thing to @goldilocks answer, except to wonder why the sudo command executes even if the information in /etc/hosts is missing or incorrect?

  1. df -h ==> 100% usage of /dev/root

I was unable to replicate this error on either my buster or bullseye RPi. I did find it curious that df -h lists /dev/root - which AFAICS isn't defined on RPi. This reference shed little light - except that this related blog post was interesting. The fact that RPi's /proc/cmdline contains root=PARTUUID=6c586e13-02 may suggest a system-level disconnect between /dev/root and / under some circumstances. A guess is that this is unique to RPi.

Seamus
  • 21,900
  • 3
  • 33
  • 70