Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 877084

Summary: missing hostname after upgrade to NetworkManager-0.9.7.0-6.git20121004.el7.x86_64
Product: Red Hat Enterprise Linux 7 Reporter: Matěj Cepl <mcepl>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED CURRENTRELEASE QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: jklimes, psimerda, pvine, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-0.9.7.0-10.git20121004.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 12:36:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
grep NetworkManager /var/log/messages
none
[PATCH] fix the race in getting hostname through reverse-lookup none

Description Matěj Cepl 2012-11-15 16:39:36 UTC 
Description of problem:
After upgrade to NetworkManager-0.9.7.0-6.git20121004.el7.x86_64 my system suddenly doesn't have a hostname anymore.

When investigating the issue, I have checked that /etc/hostname is available:

wycliff:~ $ cat /etc/hostname
wycliff.ceplovi.cz

But when checking /etc/sysconfig/network I found that it contains only line

wycliff:~ $ cat /etc/sysconfig/network
NETWORKING=yes

When I have added

HOSTNAME=wycliff.ceplovi.cz

I was able to set the hostname with hostname -f /etc/hostname

The documentation (/usr/share/doc/initscripts-*/sysconfig.txt) says

  HOSTNAME=<fqdn by default, but whatever hostname you want>
   Note that this can be overriden by /etc/hostname.

Which IMHO implies that when /etc/hostname is set, it should work as well.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.7.0-6.git20121004.el7.x86_64

How reproducible:
happened once

Steps to Reproduce:
1.see above
2.
3.
  
Actual results:
there is no FQDN set and basic (non-FQDN) hostname is empty
value of HOSTNAME is not removed from /etc/sysconfig/network

Expected results:
values set in /etc/hostname and /etc/sysconfig/network (in this order) are the configuration files are not changed without my consent.

Additional info:
Comment 1 Pavel Šimerda (pavlix) 2012-11-15 16:44:10 UTC 
commit a7eb3476557dae28880333544c797705ee2f5b5a
Author: Dan Winship <danw>
Date:   Tue Jun 19 10:07:17 2012 -0400

    ifcfg-rh: /etc/hostname should override /etc/sysconfig/network
    
    When determining the system hostname, /etc/hostname should override
    /etc/sysconfig/network, so monitor both files.
    
    When setting the hostname, set it in /etc/hostname, and delete the
    /etc/sysconfig/network HOSTNAME entry if present.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=831735
Comment 2 Matěj Cepl 2012-12-10 15:28:55 UTC 
With version NetworkManager-0.9.7.0-7.git20121004.el7.x86_64 I can still reproduce this bug on wired network. Surprisingly, everything works OK on wifi network.
Comment 3 Dan Williams 2012-12-10 15:51:16 UTC 
(In reply to comment #2)
> With version NetworkManager-0.9.7.0-7.git20121004.el7.x86_64 I can still
> reproduce this bug on wired network. Surprisingly, everything works OK on
> wifi network.

This will get fixed whenever we build the next el7 snapshot.
Comment 4 Jirka Klimes 2012-12-10 16:05:55 UTC 
It should be fixed in NetworkManager-0.9.7.0-10.git20121004.el7, now available.
Comment 6 Matěj Cepl 2012-12-17 16:55:29 UTC 
Created attachment 664980 [details]
grep NetworkManager /var/log/messages

(In reply to comment #4)
> It should be fixed in NetworkManager-0.9.7.0-10.git20121004.el7, now
> available.

But it isn't. I still can reproduce with

NetworkManager-0.9.7.0-10.git20121004.el7.x86_64
Comment 7 Jirka Klimes 2012-12-17 19:12:08 UTC 
Setting hostname call was added to handler for connection activated state in bug 875085.

Unfortunately, it shows up there is a race in updating DNS and doing reverse-lookup to get hostname.
Apparently the commit for reducing resolv.conf changes broke this as well: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=500315329765831d242d51d6a46f1e05869c15d2


bad case:
=========
...
NetworkManager[29712]: <debug> [1355769422.513260] [nm-policy-hostname.c:167] hostname4_thread_new(): (0xc5a5a0) started IPv4 reverse-lookup thread for address '1.2.3.4'
NetworkManager[29712]: <debug> [1355769422.513332] [nm-dns-manager.c:1016] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration changed
NetworkManager[29712]: <debug> [1355769422.513332] [nm-policy-hostname.c:95] hostname_thread_worker(): (0xc5a5a0) starting address reverse-lookup
NetworkManager[29712]: <debug> [1355769422.513822] [nm-policy-hostname.c:107] hostname_thread_worker(): (0xc5a5a0) address reverse-lookup returned hostname 'localhost.localdomain'
NetworkManager[29712]: <debug> [1355769422.513841] [nm-policy-hostname.c:119] hostname_thread_worker(): (0xc5a5a0) scheduling address reverse-lookup result handler
NetworkManager[29712]: <debug> [1355769422.513349] [nm-dns-manager.c:1020] nm_dns_manager_end_updates(): (update_routing_and_dns): no DNS changes to commit (1)
NetworkManager[29712]: <debug> [1355769422.515162] [nm-dns-manager.c:1016] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration changed
NetworkManager[29712]: <debug> [1355769422.515177] [nm-dns-manager.c:1025] nm_dns_manager_end_updates(): (device_state_changed): committing DNS changes (0)
NetworkManager[29712]: <debug> [1355769422.515190] [nm-dns-manager.c:592] update_dns(): updating resolv.conf
[Thread 0x7fffe8bed700 (LWP 30052) exited]
NetworkManager[29712]: <debug> [1355769422.549823] [nm-policy-hostname.c:84] hostname_thread_run_cb(): (0xc5a5a0) calling address reverse-lookup result handler
NetworkManager[29712]: <debug> [1355769422.551364] [nm-policy-hostname.c:129] hostname_thread_free(): (0xc5a5a0) freeing reverse-lookup thread
...


good case:
==========
...
NetworkManager[29712]: <debug> [1355769434.874385] [nm-policy-hostname.c:167] hostname4_thread_new(): (0xc2e400) started IPv4 reverse-lookup thread for address '1.2.3.4'
NetworkManager[29712]: <debug> [1355769434.874454] [nm-dns-manager.c:1016] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration changed
NetworkManager[29712]: <debug> [1355769434.874476] [nm-dns-manager.c:1020] nm_dns_manager_end_updates(): (update_routing_and_dns): no DNS changes to commit (1)
NetworkManager[29712]: <debug> [1355769434.874508] [nm-dns-manager.c:1016] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration changed
NetworkManager[29712]: <debug> [1355769434.874655] [nm-dns-manager.c:1025] nm_dns_manager_end_updates(): (device_state_changed): committing DNS changes (0)
NetworkManager[29712]: <debug> [1355769434.874677] [nm-dns-manager.c:592] update_dns(): updating resolv.conf
NetworkManager[29712]: <debug> [1355769434.878490] [nm-policy-hostname.c:95] hostname_thread_worker(): (0xc2e400) starting address reverse-lookup
NetworkManager[29712]: <debug> [1355769437.314422] [nm-dns-manager.c:998] nm_dns_manager_begin_updates(): (device_ip6_config_changed): queueing DNS updates (1)
NetworkManager[29712]: <debug> [1355769437.315607] [nm-dns-manager.c:1016] nm_dns_manager_end_updates(): (nm_dns_manager_end_updates): DNS configuration did not change
NetworkManager[29712]: <debug> [1355769437.315632] [nm-dns-manager.c:1020] nm_dns_manager_end_updates(): (device_ip6_config_changed): no DNS changes to commit (0)
NetworkManager[29712]: <debug> [1355769439.883342] [nm-policy-hostname.c:107] hostname_thread_worker(): (0xc2e400) address reverse-lookup returned hostname 'dhcp129-108.brq.redhat.com'
NetworkManager[29712]: <debug> [1355769439.883400] [nm-policy-hostname.c:119] hostname_thread_worker(): (0xc2e400) scheduling address reverse-lookup result handler
...
Comment 8 Dan Williams 2012-12-18 17:34:01 UTC 
So, looks to me like we're attempting to look up the hostname before we have set the DNS servers in resolv.conf perhaps?  Which is likely because update_system_hostname() gets called before nm_dns_manager_end_updates().  So here's what we should do, I think...

1) Add a signal to the dns-manager for "config-changed" and emit that when resolv.conf actually gets written
2) Policy sets a boolean in private data for "hostname lookup needed" and starts a lookup
3) this boolean *only* gets cleared when we have a hostname from other sources, it does not get cleared when the hostname lookup thread finishes
4) when the policy gets the 'config-changed' signal from the dns-manager, it cancels any existing lookup, and if the "hostname lookup needed" boolean is set, starts a new lookup

We need the boolean to ensure that if the hostname thread exited before the config-changed signal is emitted, that we kick off a new lookup.  Does that sound workable?  Just brainstorming here.
Comment 9 Jirka Klimes 2013-02-06 11:48:12 UTC 
Created attachment 693874 [details]
[PATCH] fix the race in getting hostname through reverse-lookup

The described procedure looks good. I've just changed the boolean to IPv4 and IPv6 addresses as we need them when re-running the lookup.

Some quick tests shows the patch fixes the issue.

See jklimes/hostname-fixes that includes the fix and another related clean-up:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=jklimes/hostname-fixes
Comment 10 Dan Williams 2013-02-11 18:43:36 UTC 
(In reply to comment #9)
> Created attachment 693874 [details]
> [PATCH] fix the race in getting hostname through reverse-lookup
> 
> The described procedure looks good. I've just changed the boolean to IPv4
> and IPv6 addresses as we need them when re-running the lookup.
> 
> Some quick tests shows the patch fixes the issue.
> 
> See jklimes/hostname-fixes that includes the fix and another related
> clean-up:
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=jklimes/
> hostname-fixes

Looks good; one comment though.  When converting the addresses for the debug print, if the address is the full size allowed, the buffer  wont' be NULL terminated. So you'll want to do INET_ADDRSTRLEN + 1 and INET6_ADDRSTRLEN + 1 and then either memset() the buffer or set the last char to 0 before calling inet_ntop(), and pass sizeof(buf) - 1 to inet_ntop() too.
Comment 11 Jirka Klimes 2013-02-12 15:07:22 UTC 
(In reply to comment #10)
> Looks good; one comment though.  When converting the addresses for the debug
> print, if the address is the full size allowed, the buffer  wont' be NULL
> terminated. So you'll want to do INET_ADDRSTRLEN + 1 and INET6_ADDRSTRLEN +
> 1 and then either memset() the buffer or set the last char to 0 before
> calling inet_ntop(), and pass sizeof(buf) - 1 to inet_ntop() too.

Actually, this is not necessary. INET_ADDRSTRLEN and INET6_ADDRSTRLEN macros are defined so that the length is big enough to include maximum address string including NULL character. And inet_ntop() NULL-terminates the string.

http://www.informit.com/articles/article.aspx?p=169505&seqNum=7

http://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/inet_ntop.c;h=6e89f2d0589ad0132c6b35f5e736014d9da02583;hb=HEAD#l78

The code has been merged into master:
07c5651a364622dbb97960cfa24f730f490a4f1a
2c69caf2d516545b0cfcc2f805fff2bb56b28fe5

and cherry-picked to nm-0-9-8:
cd480fe73b3082022f188e6c99c9aadff22caadf
be2e0c8adc0bfafd6489ad4e208d779815d3df49

Thanks for the review!
Comment 12 Dan Williams 2013-02-12 15:35:55 UTC 
(In reply to comment #11)
> (In reply to comment #10)
> > Looks good; one comment though.  When converting the addresses for the debug
> > print, if the address is the full size allowed, the buffer  wont' be NULL
> > terminated. So you'll want to do INET_ADDRSTRLEN + 1 and INET6_ADDRSTRLEN +
> > 1 and then either memset() the buffer or set the last char to 0 before
> > calling inet_ntop(), and pass sizeof(buf) - 1 to inet_ntop() too.
> 
> Actually, this is not necessary. INET_ADDRSTRLEN and INET6_ADDRSTRLEN macros
> are defined so that the length is big enough to include maximum address
> string including NULL character. And inet_ntop() NULL-terminates the string.

And today I learned something new :)  I even re-read inet_ntop() manpage to see if it said *anything* about ensuring NULL-termination and couldn't find anything at all.  Oh well, less confusing code then.  I'm sure there's various [INET_ADDRSTRLEN + 1] bits littered all around the code; perhaps at some point we should clean those up.
Comment 15 Vladimir Benes 2014-02-13 15:09:40 UTC 
after clean install hostname is set
Comment 16 Ludek Smid 2014-06-13 12:36:27 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.