Re: Temporary failure in name resolution
On 11/01/2024 10:19, Greg Wooledge wrote:
On Thu, Jan 11, 2024 at 10:10:43AM +0700, Max Nikulin wrote:
On 11/01/2024 03:25, Greg Wooledge wrote:
On Wed, Jan 10, 2024 at 07:19:41PM +0000, Rodolfo Medina wrote:
Greg Wooledge <greg@wooledge.org> writes:
What is the output of "grep -F $(hostname) /etc/hosts"?
127.0.1.1 caterina-thinkpad.home caterina-thinkpad
I would say that it is better to fix discrepancy between (likely)
/etc/hostname and /etc/hosts and to use a consistent name. If "thinkpad" is
the preferred one then update /etc/hosts otherwise check
I wouldn't
want to assume that nothing is using the name "caterina-thinkpad", so it
would be wise to retain it.
A fair point. Adding FQDN and "thinkpad" before existing names should be
better. I would still try to find and fix existing occurrences of the
old name
grep -r caterina-thinkpad /etc
or even "grep -R"
Also, for the love of glob, WHY THE SYSTEMD bullshit... you change the
hostname on Debian by editing the /etc/hostname file, and then by
running the "hostname" command as root with the new name as its
argument (or rebooting).
I don't know why "hostnamectl" even exists as a concept. It's repulsive.
It also fails to be init-system-agnostic, with no upside to compensate.
I assume that systemd is the default, otherwise the chance that the user
knows lower level commands is higher. hostnamectl changes both the
/etc/hostname file and kernel runtime state, so it ensures consistent
configuration. Moreover, I expect that more services using hostname are
notified and will not use the stale name. Candidates may be (while I am
unsure if it really applicable) bluetoothd, multicast DNS responder for
names and service discovery queries, and perhaps more.
Perhaps hostname was changed from GUI and it is similar to hostnamectl.
Reply to: