Bug 319981 - hostname -s gives hostname: Unknown host when the FQDN does not resolve
hostname -s gives hostname: Unknown host when the FQDN does not resolve
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-tools (Show other bugs)
5.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Popelka
qe-baseos-daemons
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-05 07:14 EDT by Simon J Mudd
Modified: 2014-02-27 06:47 EST (History)
6 users (show)

See Also:
Fixed In Version: net-tools-1.60-82.el5
Doc Type: Bug Fix
Doc Text:
Previously, the "hostname -s" command could return the "hostname: Unknown host" error message on a host if a host name was not resolved in DNS (Domain Name System). The utility has been modified and now always returns a short host name instead of the error message.
Story Points: ---
Clone Of:
: 531702 (view as bug list)
Environment:
Last Closed: 2012-02-21 00:40:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch which makes "hostname -s" display host name cut at the first dot (no matter if the host name resolves or not). (961 bytes, patch)
2009-10-26 11:49 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
Description Simon J Mudd 2007-10-05 07:14:12 EDT
Description of problem:

If you run hostname -s on a host with a hostname that does not resolve in the
DNS then you get the following error:

[root@ams03 COS4 ~]# hostname some.thing.stupid
[root@ams03 COS4 ~]# hostname
some.thing.stupid
[root@ams03 COS4 ~]# hostname -s
hostname: Unknown host

However the hostname(1) says:

      -s, --short
              Display the short host name. This is the host name cut at the
first dot.

It does not say anything about whether the hostname should resolve or not.
If the man page is wrong please fix the man page.

Version-Release number of selected component (if applicable):

Seen on:

CentOS-4, net-tools-1.60-37.EL4.9
CentOS-5, net-tools-1.60-73
RHEL4, net-tools-1.60-37.EL4.6 (redhat-release-4ES-4.1)
Fedora 7, net-tools-1.60-82.fc7

How reproducible:

Easily:

Steps to Reproduce:
1. run hostname -s on a server whose Fully qualified hostname does not resolve
in the DNS.
2. DO NOT use test.com as this domain exists!
  
Actual results:

[root@ams03 COS4 ~]# hostname
ams03.wl0.org
[root@ams03 COS4 ~]# hostname -s
ams03
[root@ams03 COS4 ~]# hostname some.thing.stupid
[root@ams03 COS4 ~]# hostname
some.thing.stupid
[root@ams03 COS4 ~]# hostname -s
hostname: Unknown host
[root@ams03 COS4 ~]# which hostname
/bin/hostname
[root@ams03 COS4 ~]# rpm -q centos-release
centos-release-4-4.3
[root@ams03 COS4 ~]# rpm -qf /bin/hostname
net-tools-1.60-37.EL4.9

Expected results:

[root@ams03 COS4 ~]# hostname
ams03.wl0.org
[root@ams03 COS4 ~]# hostname -s
ams03
[root@ams03 COS4 ~]# hostname some.thing.stupid
[root@ams03 COS4 ~]# hostname
some.thing.stupid
[root@ams03 COS4 ~]# hostname -s
some
Comment 1 Radek Vokal 2008-05-12 09:59:21 EDT
yes, this is the way it's supposed to work and I agree that it should be
documented. 
Comment 2 Simon J Mudd 2008-05-12 11:31:20 EDT
(In reply to comment #1)
> yes, this is the way it's supposed to work and I agree that it should be
> documented. 

Why is this the way it's supposed to work. It certainly doesn't seem intuitive.
What happens to a host not connected on the internet which does not use DNS?

I've also checked the man pages for various other versions of unix:
- FreeBSD/OpenBSD/AIX and they all pretty much say the same:

-s    Trim off any domain information from the printed name.

There is no mention of DNS problems breaking this so I can't see why current
behaviour is considered correct. Can you explain why you consider current
behaviour correct?
Comment 4 RHEL Product and Program Management 2009-03-26 13:03:30 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 5 Jiri Popelka 2009-09-08 12:43:21 EDT
I have this line
127.0.0.1 dhcp-lab-229.englab.brq.redhat.com localhost.localdomain localhost
in  my /etc/hosts.

If I want to add some.thing.stupid alias for
host name dhcp-lab-229.englab.brq.redhat.com
the line will look like
127.0.0.1 dhcp-lab-229.englab.brq.redhat.com localhost.localdomain localhost  some.thing.stupid

After I set host name to alias some.stupid.thing
> hostname some.thing.stupid
and type
> hostname -s
I get "dhcp-lab-229", which is in my opinion right,
because I want to see short host name, not short alias for that host name.

If I set the host name to wrong alias
> hostname some.thing.wrong
and type
> hostname -s
I get "Unknown host" warning, which is from my POV also right,
because I want to see short host name and if the host name for
some.thing.wrong cannot be resolved I want to be warned
that there's something wrong with some.thing.wrong

So I agree with Radek, that this is correct behavior.

I'm going to add this additional information to hostname man page:
> When hostname is called with -s, -a, -i, -f or -d the gethostbyname(3) will be called.
> If gethostbyname(3) cannot resolve host name, "Unknown host" warning is returned.
Comment 7 Simon J Mudd 2009-10-05 02:34:51 EDT
I still thing the WRONG solution is to document the current behaviour. Please remember that inconsistent behaviour on different unix (or unix-like) platforms is not desirable, so having RedHat Linux/Fedora's hostname behave differently to other versions of unix is undesirable, UNLESS there is a very good reason for the difference.

IMO, if you decide on a hostname for a box then that is "valid". It doesn't matter whether it's in the DNS or not. In fact hostname some.thing.very.long is accepted fine with not complaints.  As that is the case hostname -s SHOULD provide (as documented) the short version of this name, "some".

DNS issues are something completely different. hostname is ONLY used to identify the server "internally".

I use many scripts to identify the server as part of logging, precisely by using hostname -s. (Look at normal syslog output).  These scripts will not log correctly if the DNS stops working. Again this seems unexpected.

I certainly agree that if DNS is being used, and it's common, or almost always being used these days that it is HELPFUL if the hostname is valid in the DNS.

However, I don't see this as a requirement, and making commands like hostname -s fail because of DNS issues seems unhelpful.

As such I respectfully request that you make the behaviour CONSISTENT with other versions of unix (*BSD, AIX, Solaris, ...), unless you can show that their behaviour is the same in these circumstances.
Comment 8 Simon J Mudd 2009-10-05 11:08:26 EDT
Run on an AIX 5.3 server:

root@l2-bm23-e0g:/root
# hostname some.thing.long
some.thing.long
root@l2-bm23-e0g:/root
# hostname
some.thing.long
root@l2-bm23-e0g:/root
# hostname -s
some
root@l2-bm23-e0g:/root
# uname -a
AIX l2-bm23-e0g 3 5 00C056F04C00

No errors given using hostname -s.
Comment 9 Simon J Mudd 2009-10-05 16:54:11 EDT
This is the result on mac os x (10.5.8):

morticia:~ root# uname -a
Darwin morticia.tzadaah.com 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
morticia:~ root# hostname
morticia.tzadaah.com
morticia:~ root# hostname some.thing.long
morticia:~ root# hostname
some.thing.long
morticia:~ root# hostname -s
some

root@wednesday ~]# uname -a
FreeBSD wednesday.tzadaah.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May  1
07:18:07 UTC 2009
root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
[root@wednesday ~]# hostname
wednesday.tzadaah.com
[root@wednesday ~]# hostname some.thing.long
[root@wednesday ~]# hostname
some.thing.long
[root@wednesday ~]# hostname -s
some

So 2 other UNIXes have no problems with a short hostname which does not resolve.
Comment 11 Jiri Popelka 2009-10-26 11:48:31 EDT
Hi Simon

I changed my mind.
Your arguments are right, so I'm going to change the hostname -s functionality to be consistent with *BSD, AIX, MacOsX and with documentation.

Moreover I spoke to hostname maintainers in Debian (Debian's hostname -s now works the same way as RHEL's) and they are ok with this change, so it will be consistent also with Debian's hostname -s.
Comment 12 Jiri Popelka 2009-10-26 11:49:46 EDT
Created attachment 366118 [details]
Patch which makes "hostname -s" display host name cut at the first dot (no matter if the host name resolves or not).
Comment 13 RHEL Product and Program Management 2009-11-06 13:46:29 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 16 Dmitry Bolkhovityanov 2010-01-29 00:07:01 EST
Jim, is this bug going to be fixed in upcoming RHEL6?
Comment 17 Jiri Popelka 2010-01-29 04:17:11 EST
Dmitry, yes it is.
It's already fixed in Fedora (Bug #531702).
Comment 19 RHEL Product and Program Management 2010-08-09 14:25:19 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 20 Dmitry Bolkhovityanov 2010-08-09 23:55:20 EDT
(In reply to comment #19)
> Because the affected component is not scheduled to be updated in the
> current release, Red Hat is unfortunately unable to address this
> request at this time.

The above comment seems a bit ambiguous in the light of comment #17.

Which release is named "current" -- RHEL5 or RHEL6?
Comment 21 Jiri Popelka 2010-08-10 04:02:35 EDT
> Which release is named "current" -- RHEL5 or RHEL6?    
Dmitry, this bug is filled against RHEL-5 (see Product:) and comment #19 says that net-tools won't be updated in RHEL-5.6.
A I said in comment #17, this problem is already fixed in RHEL-6.
Comment 23 RHEL Product and Program Management 2011-01-11 15:36:12 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 24 RHEL Product and Program Management 2011-01-11 18:08:36 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 25 RHEL Product and Program Management 2011-05-31 09:27:44 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 30 Eliska Slobodova 2011-10-07 05:09:18 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the "hostname -s" command could return the "hostname: Unknown host" error message on a host if a host name was not resolved in DNS (Domain Name System). The utility has been modified and now always returns a short host name instead of the error message.
Comment 32 errata-xmlrpc 2012-02-21 00:40:38 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0188.html
Comment 33 xcraft360 2014-02-27 01:32:03 EST
hi guys,
i have been using the hostname command to change hostname on CentOS. but when i use the same command on Red Hat and reboot it returns back to the previous hostname.
Comment 34 Jiri Popelka 2014-02-27 04:05:37 EST
(In reply to xcraft360 from comment #33)
> when i use the same command on Red Hat and reboot it returns back to the
> previous hostname.

Set variable HOSTNAME in /etc/sysconfig/network
If you need more help, write to my email, your problem is unrelated to this ticket.
Comment 35 xcraft360 2014-02-27 06:47:36 EST
(In reply to Jiri Popelka from comment #34)
> (In reply to xcraft360 from comment #33)
> when i use the same command on
> Red Hat and reboot it returns back to the
> previous hostname.

Set variable
> HOSTNAME in /etc/sysconfig/network
If you need more help, write to my email,
> your problem is unrelated to this ticket.

thanx jiri really appreciate it...

Note You need to log in before you can comment on or make changes to this bug.