Bug 831735 - NetworkManager should not touch the hostname
NetworkManager should not touch the hostname
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
: 882673 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-13 12:34 EDT by David Zeuthen
Modified: 2013-03-05 23:08 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-06 23:26:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch (7.68 KB, patch)
2012-06-19 10:11 EDT, Dan Winship
no flags Details | Diff
updated patch (7.83 KB, patch)
2012-06-25 13:16 EDT, Dan Winship
no flags Details | Diff

  None (edit)
Description David Zeuthen 2012-06-13 12:34:21 EDT
I have a F17 system where the /etc/sysconfig/network file has the line

 HOSTNAME=(none)

and the /etc/hostname file has the line

 mycomputer

On startup, I'd expect systemd to call sethostname("mycomputer") but it appears to do sethostname("(none)") instead.
Comment 1 Kay Sievers 2012-06-13 12:49:25 EDT
I see the same. Maybe some tool reads sysconfig and re-sets it.

# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=foo
NTPSERVERARGS=iburst

# cat /etc/hostname 
mop

# cat /proc/sys/kernel/hostname 
foo

# dmesg | grep hostname
[    1.467693] systemd[1]: Set hostname to <mop>.
Comment 2 David Zeuthen 2012-06-13 12:50:22 EDT
Actually, sorry, this is a bug with NetworkManager

 Jun 13 12:14:39 (none) NetworkManager[530]: <info> Setting system hostname to '(none)' (from system configuration)

Reassigning.
Comment 3 Dan Winship 2012-06-13 14:10:31 EDT
NM has hostname-changing code so that if your machine has no canonical name, NM can set its hostname based on the address it gets back from DHCP. However, it only does this if your machine doesn't have a canonical name set; the bug here is just that NM doesn't realize that /etc/hostname is supposed to override /etc/sysconfig/network, so it thinks "mycomputer" was a transient hostname someone else set, and it's "fixing" it for you.
Comment 4 Dan Winship 2012-06-13 14:19:18 EDT
Well, I suppose we should just replace the current file-based hostname reading/setting/monitoring code with code that uses hostnamed via D-Bus.
Comment 5 Dan Winship 2012-06-19 09:43:09 EDT
(In reply to comment #4)
> Well, I suppose we should just replace the current file-based hostname
> reading/setting/monitoring code with code that uses hostnamed via D-Bus.

except that (a) hostnamed doesn't actually monitor the filenames, it assumes all changes will go through hostnamed, which I'm not sure we want to assume, and (b) hostnamed doesn't look at /etc/sysconfig/network.
Comment 6 Dan Winship 2012-06-19 10:11:40 EDT
Created attachment 592972 [details]
patch
Comment 7 Dan Williams 2012-06-20 13:35:06 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Well, I suppose we should just replace the current file-based hostname
> > reading/setting/monitoring code with code that uses hostnamed via D-Bus.
> 
> except that (a) hostnamed doesn't actually monitor the filenames, it assumes
> all changes will go through hostnamed, which I'm not sure we want to assume,
> and (b) hostnamed doesn't look at /etc/sysconfig/network.

Yeah, I don't think we can assume that all changes go through hostnamed.  hostnamed has to monitor the files on-disk for changes made via CLI or provide some mechanism (HUP perhaps, since davidz dislikes file watches for config change notifications) for users that make changes directly to the files to notify hostnamed of the new name.  Perhaps we need to put a comment into /etc/hostname that says "if you modify this file, send SIGHUP to hostnamed" to make sure people know what they need to do.
Comment 8 Dan Williams 2012-06-20 13:51:38 EDT
Patch review:

1) In sc_plugin_ifcfg_init() you probably also want to assign the GFileMonitor for /etc/hostname to priv->hostname_monitor and same for the source ID.

2) we still need the inotify helper code because GIO cannot deliver change notifications for hardlinked files when one of the other hardlinks changes, and unfortunately /etc/sysconfig/network is a hardlinked file.  So we probably need *both* the GFileMonitor and the inotify helper here for /etc/sysconfig/network, but both just eventually need to call the same code that reads & compares the hostname.
Comment 9 Dan Winship 2012-06-25 13:16:52 EDT
Created attachment 594242 [details]
updated patch

fix the cut+paste bug, and revert back to using inotify for SC_NETWORK_FILE.

To simplify things, I left it using just inotify for SC_NETWORK_FILE (since it's unlikely that file would ever not exist, and since this is what we always did before anyway), and just GFileMonitor for HOSTNAME_FILE (since it's unlikely that /etc/hostname will be a hard link). Eventually they can both use just GFileMonitor...
Comment 10 Daniel Drake 2012-10-30 11:21:22 EDT
It might be important to finish this work off now that the /etc/hostname direction has been further solidified in F18:

http://lists.fedoraproject.org/pipermail/test/2012-October/111230.html

That said, I couldn't reproduce the original issue noted in this bug report, maybe because systemd sets the hostname from /etc/hostname early during boot.
Comment 11 Dan Williams 2012-11-02 11:14:59 EDT
(In reply to comment #9)
> Created attachment 594242 [details]
> updated patch
> 
> fix the cut+paste bug, and revert back to using inotify for SC_NETWORK_FILE.
> 
> To simplify things, I left it using just inotify for SC_NETWORK_FILE (since
> it's unlikely that file would ever not exist, and since this is what we
> always did before anyway), and just GFileMonitor for HOSTNAME_FILE (since
> it's unlikely that /etc/hostname will be a hard link). Eventually they can
> both use just GFileMonitor...

Looks good, land it.
Comment 12 Dan Winship 2012-11-02 11:25:25 EDT
fixed in git... will update this after the next import
Comment 13 Jirka Klimes 2012-12-04 10:38:55 EST
*** Bug 882673 has been marked as a duplicate of this bug. ***
Comment 14 Fedora Update System 2012-12-05 06:54:53 EST
NetworkManager-0.9.7.0-9.git20121004.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.7.0-9.git20121004.fc18
Comment 15 Fedora Update System 2012-12-05 18:16:19 EST
Package NetworkManager-0.9.7.0-9.git20121004.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.7.0-9.git20121004.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19813/NetworkManager-0.9.7.0-9.git20121004.fc18
then log in and leave karma (feedback).
Comment 16 Fedora Update System 2012-12-06 23:26:39 EST
NetworkManager-0.9.7.0-9.git20121004.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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