NM 0.7 sets hostname to localhost.localdomain instead of what is in /etc/hostname

Bug #276253 reported by Alexander Sack on 2008-09-30
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Critical
Unassigned
Intrepid
Critical
Unassigned

Bug Description

Binary package hint: network-manager

latest NM 0.7 sets hostname to localhost.localdomain if there is no hostname configured in system settings plugins.

workaround is to add

[keyfile]
hostname=YOURHOSTNAME

to /etc/NetworkManager/nm-system-settings.conf when using the keyfile plugin.

Alexander Sack (asac) wrote :

quite serious issue. especially since we dont setup ifupdown system settings plugin by default yet.

Changed in network-manager:
importance: Undecided → High
status: New → Triaged
milestone: none → ubuntu-8.10
Alexander Sack (asac) wrote :

works for me. setting to fix committed.

Changed in network-manager:
status: Triaged → Fix Committed
Changed in network-manager:
importance: High → Critical
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager - 0.7~~svn20080928t225540+eni0-0ubuntu2

---------------
network-manager (0.7~~svn20080928t225540+eni0-0ubuntu2) intrepid; urgency=low

  [ Alexander Sack <email address hidden> ]
  * remove patches forwarded/applied upstream
    - delete debian/patches/80_lp259503_access_to_freed_device_struct.patch
    - delete debian/patches/honour_resolvconf_exitcode.patch
    - delete debian/patches/lp269010_keyfile_secrets_crash.patch
    - update debian/patches/series
  * LP: #276253 - NM 0.7 sets hostname to localhost.localdomain instead of
    what is in /etc/hostname - we fallback to hostname configured in
    /etc/hostname even when no distro specific system plugin is enabled; we
    do this for all cases until a proper solution was found.
    - add debian/patches/fix_system_hostname.patch
    - update debian/patches/series

  [ Matt Zimmerman <email address hidden> ]
  * (apport hook) Use [].append rather than the += operator, to avoid things
    like: "InterestingModules: b 4 4" (should be b44)
    - update debian/source_network-manager.py

 -- Alexander Sack <email address hidden> Thu, 02 Oct 2008 20:37:20 +0200

Changed in network-manager:
status: Fix Committed → Fix Released
Mark A. Hershberger (hexmode) wrote :

I just upgraded to Intrepid and am seeing this. System would come up and set the name to "localhost.localdomain" and then "localhost" even though I had a name in /etc/hostname.

Worse, my X session is started under the name "localhost.localdomain" and the hostname changes. After the name changes, I can't start any programs because the X server refuses to talk to them (unless I manually set the hostname or use "xhost +")

From my log file:

Dec 13 11:35:32 dococt NetworkManager: <info> Setting system hostname to 'localhost.localdomain' (no default device)
Dec 13 11:36:22 dococt NetworkManager: <info> hostname 'localhost'

(Evidently the name is correctly set by /etc/init.d/hostname.sh during startup since syslog is logging "dococt" and not "localhost" or some variant.)

On Sun, Dec 14, 2008 at 03:14:15AM -0000, Mark A. Hershberger wrote:
> I just upgraded to Intrepid and am seeing this. System would come up
> and set the name to "localhost.localdomain" and then "localhost" even
> though I had a name in /etc/hostname.
>
> Worse, my X session is started under the name "localhost.localdomain"
> and the hostname changes. After the name changes, I can't start any
> programs because the X server refuses to talk to them (unless I manually
> set the hostname or use "xhost +")
>
> >From my log file:
>
> Dec 13 11:35:32 dococt NetworkManager: <info> Setting system hostname to 'localhost.localdomain' (no default device)
> Dec 13 11:36:22 dococt NetworkManager: <info> hostname 'localhost'
>
> (Evidently the name is correctly set by /etc/init.d/hostname.sh during
> startup since syslog is logging "dococt" and not "localhost" or some
> variant.)
>

is nm-system-settings process running ... and what do you have in
/etc/NetworkManager/nm-system-settings.conf?

 - Alexander

Simon Ruggier (simon80) wrote :

I'm seeing this on a Jaunty system that I've cloned from one machine to another using tar. Since /etc/init.d/hostname already takes care of this, I don't understand why NetworkManager would ever need to trash a system's hostname. Relevant stuff from /var/log/daemon.log attached.

Robert Citek (robert-citek) wrote :

I'm seeing a similar issue with 8.10. My solution was to disable network manager:

$ cd /etc/rc2.d
$ sudo mv S28NetworkManager K01NetworkManager

This is a very bad solution for those who want to manage their networks from within Gnome, but since I don't, it works for me.

Some details:

$ dpkg -l network-manager | grep net
ii network-manager 0.7~~svn20081018t105859-0 network management framework daemon

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.10
Release: 8.10
Codename: intrepid

$ grep "Setting system hostname" /var/log/syslog | tail -1
Sep 9 19:09:19 foobar NetworkManager: <info> Setting system hostname to 'localhost.localdomain' (no default device)

$ cat /etc/hostname
foobar

$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.1.1 foobar
127.0.0.1 localhost.localdomain localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

nh2 (nh2) wrote :

Same problem. We use rsync to clone Jaunty systems. Can anyone explain why NetworkManager does that?

nh2 (nh2) wrote :

It even happens when

[keyfile]
hostname=mize02

is declared. There is no process "nm-system-settings" running.

Robert Citek (robert-citek) wrote :

Actually, I've "completely" disabled Network manager from starting up in any runlevel:

$ ls -la /etc/rc?.d/*Manag*
lrwxrwxrwx 1 root root 24 Jan 13 2009 /etc/rc2.d/K01S28NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx 1 root root 24 Jan 13 2009 /etc/rc3.d/K01S28NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx 1 root root 24 Jan 13 2009 /etc/rc4.d/K01S28NetworkManager -> ../init.d/NetworkManager
lrwxrwxrwx 1 root root 24 Jan 13 2009 /etc/rc5.d/K01S28NetworkManager -> ../init.d/NetworkManager

This allows me to get on the 'Net via the command line and run X-clients.

Odd that the patch is supposed to have fixed this problem in 8.10, yet, I and apparently others are still experiencing it. Do I not have the patched version installed?

I did a upgrade from 8.04 to 9.04, clearly reproducing this issue as well. A fresh install of NM isn't fixing my issues. Additionally, [keyfile] workaround is not helping me either.

Robert Citek (robert-citek) wrote :

Hello Alexander,

This is still an issue for me and others in 8.10 (Intrepid). Of note is that if I disable Network Manager then I am able to surf the Internet just fine:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/276253/comments/12

Is there any other information I can provide to help fix this bug?

Regards,
- Robert

Changed in network-manager (Ubuntu Intrepid):
status: Fix Released → Confirmed
Changed in network-manager (Ubuntu):
status: Fix Released → Confirmed
Alexander Sack (asac) wrote :

this is definitly fixed in latest NM. I dont know the status in intrepid. doesnt the workaround given in summary work? Are you using the ifupdown plugin at all?

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
Alexander Sack (asac) wrote :

it could be that nm-system-settings process crashes for you. if no such process is running, please try to run nm-system-settings with sudo from command line and see if it goes down.

Jamie Strandboge (jdstrand) wrote :

If you "clone" your hard drive with something like rsync that tries to be smart about ownership of files, then you might be running into problems because of incorrect ownership of files on the cloned drive that snowball into problems with network manager. Eg, I cloned a hard drive with rsync via an install CD using "rsync -avH ...". Well, rsync looked at /etc/passwd and /etc/group of the install CD and setup the ownership of various things wrong, including /lib/dbus-1.0/dbus-daemon-launch-helper-- which prevented network-manager from starting correctly (this was seen in /var/log/syslog). After doing the initial rsync, you must chroot into the mounted disk and perform the rsync again, to get the proper permissions. Hope this helps for those people who cloned the drive and ran into this problem....

Sergio Zanchetta (primes2h) wrote :

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

Changed in network-manager (Ubuntu Intrepid):
status: Confirmed → Won't Fix
Sergio Zanchetta (primes2h) wrote :

I realized I had made a mistake.
Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers