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
yes, this is the way it's supposed to work and I agree that it should be documented.
(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?
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 "?".
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.
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.
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.
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.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.
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.
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).
Jim, is this bug going to be fixed in upcoming RHEL6?
Dmitry, yes it is. It's already fixed in Fedora (Bug #531702).
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.
(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?
> 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.
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.
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.
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
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.
(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.
(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...