Transient hostname behaves weirdly with DHCP leases

[septatrix]

systemd version the issue has been seen with

255.4-1.fc40

Used distribution

Fedora 40

Linux kernel version used

6.8.7-300.fc40.x86_64

CPU architectures issue was seen on

x86_64

Component

systemd-hostnamed, systemd-networkd, systemd-resolved

Expected behaviour you didn't see

1. Acquiring a DHCP lease should update the hostname if one was send and preserve the existing one otherwise.
2. Losing a DHCP lease should not change the hostname if it was not obtained via DHCP and otherwise restore the previous hostname.

Unexpected behaviour you saw

1. Acquiring a DHCP lease without a hostname resets the hostname to the value set inside the initrd.
2. Losing a DHCP lease results in a reset of the hostname to the default one, i.e. "fedora".

Steps to reproduce the problem

I am using a usr-only OS image with a default hostname set in the initrd (using mkosi's Hostname= option, most importantly there is no /etc/hostname).

1. Set a transient hostname using hostnamectl --transient.
2. Open iwctl and connect to a wifi network which does not assign hostnames with DHCP leases.
3. Check the hostname with hostnamectl (or look into the journal).
4. Open iwctl and disconnect from the wifi.
5. Check the hostname with hostnamectl (or look into the journal).

Additional program output to the terminal or log subsystem illustrating the issue

Apr 28 23:57:05 Foobar iwd[606]: event: connect-info, ssid: Coldspot, bss: 50:75:f1:a3:8c:0a, signal: -36, load: 127/255
Apr 28 23:57:05 Foobar iwd[606]: event: state, old: disconnected, new: connecting
Apr 28 23:57:06 Foobar kernel: wlan0: authenticate with 50:75:f1:a3:8c:0a (local address=28:df:eb:49:07:37)
Apr 28 23:57:06 Foobar kernel: wlan0: send auth to 50:75:f1:a3:8c:0a (try 1/3)
Apr 28 23:57:06 Foobar kernel: wlan0: authenticated
Apr 28 23:57:06 Foobar kernel: wlan0: associate with 50:75:f1:a3:8c:0a (try 1/3)
Apr 28 23:57:06 Foobar kernel: wlan0: RX AssocResp from 50:75:f1:a3:8c:0a (capab=0x1011 status=0 aid=3)
Apr 28 23:57:06 Foobar systemd-networkd[495]: wlan0: Connected WiFi access point: Coldspot (50:75:f1:a3:8c:0a)
Apr 28 23:57:06 Foobar kernel: wlan0: associated
Apr 28 23:57:06 Foobar kernel: wlan0: Limiting TX power to 23 (23 - 0) dBm as advertised by 50:75:f1:a3:8c:0a
Apr 28 23:57:06 Foobar iwd[606]: event: state, old: connecting, new: connected
Apr 28 23:57:06 Foobar systemd-networkd[495]: wlan0: Gained carrier
Apr 28 23:57:06 Foobar systemd-networkd[495]: wlan0: DHCPv4 address 192.168.0.59/24, gateway 192.168.0.1 acquired from 192.168.0.1
Apr 28 23:57:06 Foobar systemd[1]: Starting systemd-hostnamed.service - Hostname Service...
Apr 28 23:57:06 Foobar systemd[1]: Started systemd-hostnamed.service - Hostname Service.
Apr 28 23:57:06 Digital-Signage-Player systemd-resolved[577]: System hostname changed to 'Digital-Signage-Player'.
Apr 28 23:57:06 Digital-Signage-Player systemd-hostnamed[1944]: Hostname set to <Digital-Signage-Player> (transient)
Apr 28 23:57:07 Digital-Signage-Player systemd-networkd[495]: wlan0: DHCPv6 address 2a02:908:1024:9740::11c6/128 (valid for 11h 59min 59s, preferred for 11h 59min 59s)
Apr 28 23:57:12 Digital-Signage-Player iwd[606]: event: state, old: connected, new: disconnecting
Apr 28 23:57:12 Digital-Signage-Player kernel: wlan0: deauthenticating from 50:75:f1:a3:8c:0a by local choice (Reason: 3=DEAUTH_LEAVING)
Apr 28 23:57:12 Digital-Signage-Player systemd-networkd[495]: wlan0: Lost carrier
Apr 28 23:57:12 Digital-Signage-Player systemd-networkd[495]: wlan0: DHCP lease lost
Apr 28 23:57:12 Digital-Signage-Player iwd[606]: event: state, old: disconnecting, new: disconnected
Apr 28 23:57:12 Digital-Signage-Player systemd-networkd[495]: wlan0: DHCPv6 lease lost
Apr 28 23:57:12 fedora systemd-resolved[577]: System hostname changed to 'fedora'.
Apr 28 23:57:12 fedora systemd-hostnamed[1944]: Hostname set to <fedora> (default)

[poettering]

Duplicate of #17403

[septatrix]

It does not seem like this is a duplicate of the referenced issue. That one is about persisting the dhcp hostname as a static hostname whereas mine is about the behavior of the hostname when dhcp does not even send one. In that case the transient hostname seems to go bonkers, gets lost/reset or whatever.

[poettering]

@septatrix the transient hostname is transient, i.e. it lives only as long as the dhcp lease it is defined in is valid. We revert back to the static hostname once the dhcp lease ended. If no static hostname is defined, we fall back to the fallback hostname instead.

What you are asking for is that the hostname from a DHCP least is applied not just transiently, but persistently, and that's what the "static" hostname is for. Hence to me it appears this is simply the same issue?

[septatrix]

What you are asking for is that the hostname from a DHCP least is applied not just transiently, but persistently, and that's what the "static" hostname is for. Hence to me it appears this is simply the same issue?

No, I do not really care about the static hostname. My DHCP lease (to my knowledge) does not send even send any hostname - at least I never configured my router to do so.

The "Foobar" hostname is transient and was set by me. The "Digital-Signage-Player" is not from DHCP. I actually do not know where systemd gets it from. It is the one set in the initrd (and was the hostname originally before I set it to "Foobar") but I have no clue from where systemd gets this name after I overwrote it with "Foobar". Then, after the DHCP lease expires the hostname is reset to "fedora" which is the default hostname as per os-release. I would expect it to not change the hostname (because the DHCP lease never set one) or at least revert it to "Foobar".

[poettering]

The "Foobar" hostname is transient and was set by me. The "Digital-Signage-Player" is not from DHCP. I actually do not know where systemd gets it from.

this smells a lot as if it actually does come from DHCP. If you look at the sources the hostname changes the moment the dhcp lease is acquire and later lost.

maybe you have a DHCP server on your wifi you are not aware of?

consider setting UseHostname=no to make sure networkd doesn't use the hostname?

[septatrix]

The "Foobar" hostname is transient and was set by me. The "Digital-Signage-Player" is not from DHCP. I actually do not know where systemd gets it from.

this smells a lot as if it actually does come from DHCP. If you look at the sources the hostname changes the moment the dhcp lease is acquire and later lost.

maybe you have a DHCP server on your wifi you are not aware of?

Upon further inspection it seems that you are correct. The router apparently sends out hostnames - I assume to resolve hostname conflicts if several devices announce the same hostname.

consider setting UseHostname=no to make sure networkd doesn't use the hostname?

Even though we do not expect to have duplicate devices on the same network we would like to preserve the ability for our customers to assign custom hostnames if they so desire. The solution we are doing now is to adjust the hostname in os-release:

sed -i \
    -e 's/DEFAULT_HOSTNAME="fedora"/DEFAULT_HOSTNAME="Digital-Signage-Player"/' \
    "$BUILDROOT"/usr/lib/os-release

Thanks for your help!

[yuwata]

@septatrix Editing os-release per-host is not good. Using /etc/hostname (and /etc/machine-info) is better solution.

[septatrix]

@septatrix Editing os-release per-host is not good. Using /etc/hostname (and /etc/machine-info) is better solution.

We are using usr/-only images and while we do have a persistent root we try to avoid putting files. We build our images using mkosi and the above hostname really is our "default hostname" for all devices so setting the field in os-release seems like a reasonable solution.
I also opened an issue in mkosi to do this when Hostname= is present in the mkosi configuration

[yuwata]

I see. Note, if you use newer systemd, then you can use systemd.hostname= kernel command line option. (Though, I am not sure if it will be reused or not when a transient hostname is revoked.)