Red Hat Bugzilla – Bug 831735
NetworkManager should not touch the hostname
Last modified: 2013-03-05 23:08:56 EST
I have a F17 system where the /etc/sysconfig/network file has the line
and the /etc/hostname file has the line
On startup, I'd expect systemd to call sethostname("mycomputer") but it appears to do sethostname("(none)") instead.
I see the same. Maybe some tool reads sysconfig and re-sets it.
# cat /etc/sysconfig/network
# cat /etc/hostname
# cat /proc/sys/kernel/hostname
# dmesg | grep hostname
[ 1.467693] systemd: Set hostname to <mop>.
Actually, sorry, this is a bug with NetworkManager
Jun 13 12:14:39 (none) NetworkManager: <info> Setting system hostname to '(none)' (from system configuration)
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.
Well, I suppose we should just replace the current file-based hostname reading/setting/monitoring code with code that uses hostnamed via D-Bus.
(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.
Created attachment 592972 [details]
(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.
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.
Created attachment 594242 [details]
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...
It might be important to finish this work off now that the /etc/hostname direction has been further solidified in F18:
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.
(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.
fixed in git... will update this after the next import
*** Bug 882673 has been marked as a duplicate of this bug. ***
NetworkManager-0.9.7.0-9.git20121004.fc18 has been submitted as an update for Fedora 18.
* 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:
then log in and leave karma (feedback).
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.