Purpose of " 127.0.1.1 raspberrypi " entry in file /etc/hosts

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

@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?

2. 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.