#792854 isc-dhcp-client: Dhclient fails to set hostname

Package:
isc-dhcp-client
Source:
isc-dhcp
Description:
DHCP client for automatically obtaining an IP address
Submitter:
Niki Kovacs
Date:
2023-09-12 17:36:02 UTC
Severity:
minor
Tags:
#792854#5
Date:
2015-07-19 12:03:24 UTC
From:
To:
Hi,

I installed two minimal Debian Jessie 8.0 systems on two spare sandbox PCs in my office. I installed
Debian 8.0 32-bit on one PC, and Debian 8.0 64-bit on the other one.

Since I have a local Dnsmasq server, I didn't want to provide any "hardcoded" hostname information.

/etc/hostname contains only 'localhost', and similarly, /etc/hosts only has information about
'localhost' and 'localhost.localdomain'.

On the 64-bit client, the hostname gets set correctly by the server. After booting, I login to the
machine, and 'hostname' returns 'raymonde' as expected. 'hostname --fqdn' returns
'raymonde.microlinux.lan'.

On the 32-bit client (which has the exact same setup), 'hostname --fqdn' should return
'bernadette.microlinux.lan'. Unfortunately, all I get here is 'localhost.localdomain'.

Just to be on the safe side, I performed a fresh installation of a clean Debian system on each of
these client machines, one with 32-bit, one with 64-bit. The same problem arises again.

So it looks like this is a bug in dhclient which only affects 32-bit systems.

Cheers from the sunny South of France,

Niki Kovacs
#792854#10
Date:
2015-08-10 10:02:40 UTC
From:
To:
Hi Niki,

Just in case you are still facing the issue.

I have just dist-upgraded from wheezy to jessie, and I had the same
problem on 64-bit.

Removed my empty /etc/hostname file and the next reboot was OK. To
verify I recreated the empty file and the problem came back.

Hope that it helps.

Cheers from the French Alpes,

Alejandro
#792854#15
Date:
2015-09-10 13:10:07 UTC
From:
To:
Hi Alejandro,

Your solution works on 64-bit... but not on 32-bit, as described in the
initial bug report.

Dhclient showing inconsistent behavior on 32-bit and 64-bit systems
looks like a bug to me.

Cheers,

Niki
#792854#20
Date:
2015-09-12 22:35:21 UTC
From:
To:
control: tag -1 moreinfo, upstream

I don't use dnsmasq so haven't tried to reproduce, but if true It is a bug.

There really isn't enough information to go on here.  Please do some
troubleshooting (avoid network manager, networkd, resolvconf, etc.,
and other possible culprits).  Also, try reporting upstream to ISC.

Best wishes,
Mike
#792854#25
Date:
2015-09-12 22:35:21 UTC
From:
To:
control: tag -1 moreinfo, upstream

I don't use dnsmasq so haven't tried to reproduce, but if true It is a bug.

There really isn't enough information to go on here.  Please do some
troubleshooting (avoid network manager, networkd, resolvconf, etc.,
and other possible culprits).  Also, try reporting upstream to ISC.

Best wishes,
Mike
#792854#30
Date:
2015-09-13 06:45:07 UTC
From:
To:
Le 13/09/2015 00:35, Michael Gilbert a écrit :

I'm basically a Slackware user, and I gave Debian a spin out of
curiosity. Reporting a bug with Slackware is as easy as posting a
message in the LinuxQuestions forum, and a couple days later, the distro
maintainer fixes it, with a curt Thank You note in the ChangeLog.

I'll let you guys fix this, but as far as I'm concerned, there is
clearly a malfunction, so my bug report stops here.

Cheers from the sunny South of France,

Niki
#792854#35
Date:
2015-09-13 06:45:07 UTC
From:
To:
Le 13/09/2015 00:35, Michael Gilbert a écrit :

I'm basically a Slackware user, and I gave Debian a spin out of
curiosity. Reporting a bug with Slackware is as easy as posting a
message in the LinuxQuestions forum, and a couple days later, the distro
maintainer fixes it, with a curt Thank You note in the ChangeLog.

I'll let you guys fix this, but as far as I'm concerned, there is
clearly a malfunction, so my bug report stops here.

Cheers from the sunny South of France,

Niki
#792854#38
Date:
2015-09-13 06:45:07 UTC
From:
To:
Le 13/09/2015 00:35, Michael Gilbert a écrit :

I'm basically a Slackware user, and I gave Debian a spin out of
curiosity. Reporting a bug with Slackware is as easy as posting a
message in the LinuxQuestions forum, and a couple days later, the distro
maintainer fixes it, with a curt Thank You note in the ChangeLog.

I'll let you guys fix this, but as far as I'm concerned, there is
clearly a malfunction, so my bug report stops here.

Cheers from the sunny South of France,

Niki
#792854#43
Date:
2015-09-13 17:47:08 UTC
From:
To:
control: severity -1 minor

Well if you aren't willing to engage in a dialog to try to diagnose
your problem, then I have no interest either.

You ignored a perfectly reasonable suggestion from another user, which
was to backup /etc/hostname elsewhere.  Remember you specifically
state that your /etc/hostname contains "localhost".

Best wishes,
Mike
#792854#48
Date:
2015-09-13 17:47:08 UTC
From:
To:
control: severity -1 minor

Well if you aren't willing to engage in a dialog to try to diagnose
your problem, then I have no interest either.

You ignored a perfectly reasonable suggestion from another user, which
was to backup /etc/hostname elsewhere.  Remember you specifically
state that your /etc/hostname contains "localhost".

Best wishes,
Mike
#792854#53
Date:
2015-09-13 17:57:54 UTC
From:
To:
Le 13/09/2015 19:47, Michael Gilbert a écrit :

No, I did not ignore it. I gave it a try, but to no avail. Just read my
comment above.

Removing /etc/hostname works on a 64-bit architecture, but not on 32-bit
(third time's the charm).

Have fun,

Niki Kovacs
#792854#58
Date:
2015-09-13 17:57:54 UTC
From:
To:
Le 13/09/2015 19:47, Michael Gilbert a écrit :

No, I did not ignore it. I gave it a try, but to no avail. Just read my
comment above.

Removing /etc/hostname works on a 64-bit architecture, but not on 32-bit
(third time's the charm).

Have fun,

Niki Kovacs
#792854#61
Date:
2015-09-13 17:57:54 UTC
From:
To:
Le 13/09/2015 19:47, Michael Gilbert a écrit :

No, I did not ignore it. I gave it a try, but to no avail. Just read my
comment above.

Removing /etc/hostname works on a 64-bit architecture, but not on 32-bit
(third time's the charm).

Have fun,

Niki Kovacs
#792854#66
Date:
2016-11-21 13:49:36 UTC
From:
To:
Hello!

I've also faced the bug. And it's also mentioned here:
http://blog.schlomo.schapiro.org/2013/11/setting-hostname-from-dhcp-in-debian.html .

It's caused incorrect if in file /sbin/dhclient-script

I've made a patch that fixed the issue for me:

--- /root/dhclient-script       2016-11-20 07:05:32.145715966 +0300
+++ /sbin/dhclient-script       2016-11-20 07:31:06.581734208 +0300
@@ -98,10 +98,9 @@
         if [ -z "$current_hostname" ] ||
            [ "$current_hostname" = '(none)' ] ||
            [ "$current_hostname" = 'localhost' ] ||
-           [ "$current_hostname" = "$old_host_name" ]; then
-           if [ "$new_host_name" != "$old_host_name" ]; then
-               hostname "$new_host_name"
-           fi
+           ([ "$current_hostname" = "$old_host_name" ] &&
+           [ "$new_host_name" != "$old_host_name" ]); then
+               hostname "$new_host_name"
         fi
     fi
 }

Will be glad if debian includes it in a package resolving the issue.

With best regards, Ivan.
#792854#73
Date:
2016-11-26 07:45:07 UTC
From:
To:
On Mon, Nov 21, 2016 at 8:49 AM:

Does the fix applied for #604883 help?  That's been in
testing/unstable for a while now, and all of the messages in this bug
log have been about the jessie package.

Best wishes,
Mike
#792854#78
Date:
2017-01-08 23:59:14 UTC
From:
To:
version: 4.3.3-1

Since no one has stated otherwise, I'm closing this as fixed by
#604883.  If that isn't the case, please reopen.

Best wishes,
Mike
#792854#97
Date:
2023-09-12 17:23:24 UTC
From:
To:
The patch from #604883 does not help.

The current logic is clear (dhclient-script file):
        # current host name is empty, '(none)' or 'localhost' or differs from new one from DHCP
        if [ -z "$current_hostname" ] ||
           [ "$current_hostname" = '(none)' ] ||
           [ "$current_hostname" = 'localhost' ] ||
           [ "$current_hostname" == "$old_host_name" ]; then
           if [ "$new_host_name" != "$current_host_name" ]; then
               hostname "$new_host_name"
           fi

according to bug #667647 and the script:
- old_host_name is the hostname sent by the client to the DHCP server
- current_hostname is the current return value of hostname(1)
- new_host_name is the proposed hostname from DHCP (option 12)

The new hostname is set if one of that conditions are true:
- current_hostname is not set
- current_hostname is "(none)"
- current_hostname is "localhost"
- current_hostname is the same as the old_host_name

mind that current_hostname will be practically always old_host_name.

The bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667647
Is accurate describing it, and the documentation shall be changed, as this is a misbehavior compared to all the other clients, and compared to the specification of DHCP.

The patch is rather simple:

--- dhclient-script_old   2023-02-20 08:19:43.000000000 +0000
+++ dhclient-script     2023-09-12 18:08:25.172475371 +0100
@@ -128,7 +128,7 @@
         if [ -z "$current_hostname" ] ||
            [ "$current_hostname" = '(none)' ] ||
            [ "$current_hostname" = 'localhost' ] ||
-           [ "$current_hostname" = "$old_host_name" ]; then
+           [ "$current_hostname" != "$old_host_name" ]; then
            if [ "$new_host_name" != "$current_host_name" ]; then
                hostname "$new_host_name"
            fi

The logic would be then that if the hostname is different from the one provided (not the same) the proposed hostname is used.


Best,