What's the output of 

journalctl -b|grep -i hostname
cat /etc/hostname
grep -iIr 'hostname=' /etc/*

all run as root.

CC: (none) => davidwhodgins

Created attachment 12627 [details]
Command output

Here is the output of the first and third commands.  There is no /etc/hostname file at the moment as I deleted it to prevent whatever was changing it, but prior to that it contained "localhost"

Looks like the -b option was missed which makes it harder to follow.
Please reboot, then attach the output of

journalctl -b|grep -i hostname

Also, what's the contents of the /etc/rc.d/init.d/oracle-xe file?

I will make an attachment for oracle-xe, but I doubt it's that because I've been installing oracle-xe on my cauldron systems for the last 10 years (oracle-xe is about 768 lines).

Dave, the -b is clearly there on line 1 of the first attachment, but I'll reboot and retry it just to see if something in the boot process recreates /etc/hostname.

After reboot the /etc/hostname I deleted has not been recreated, so the original /etc/hostname which contained "localhost" was likely created during an rpm install or upgrade.

The result of the journalctl command is quite short with no /etc/hostname present:

Apr 14 19:57:13 localhost systemd[1]: No hostname configured, using default hostname.
Apr 14 19:57:13 localhost systemd[1]: Hostname set to <localhost>.
Apr 14 19:58:47 localhost systemd[1]: Starting Hostname Service...
Apr 14 19:58:47 localhost systemd[1]: Started Hostname Service.
Apr 14 19:58:47 localhost NetworkManager[11554]: <info>  [1618444727.7323] hostname: hostname: using hostnamed
Apr 14 19:58:53 localhost NetworkManager[11554]: <info>  [1618444733.5978] policy: set-hostname: set hostname to 'ftglap' (from DHCPv4.)
Apr 14 19:58:53 ftglap systemd-hostnamed[11585]: Hostname set to <ftglap> (transient)
Apr 14 19:59:55 ftglap systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Apr 14 20:00:00 ftglap systemd[1]: Starting Hostname Service...
Apr 14 20:00:00 ftglap systemd[1]: Started Hostname Service.
Apr 14 20:00:31 ftglap systemd[1]: systemd-hostnamed.service: Deactivated successfully.

If it would help, I can recreate /etc/hostname as it was and reboot to get another journalctl.

I'll still attach oracle-xe, but I should mention that it is disabled; I only start oracle-xe when I need it for testing for work, which is almost never.

Unfortunately, when I try to add oracle-xe as an attachment, bugzilla throws an error claiming "malformed mult-post".  I'll try attaching it as binary.

No good there either.  But as I say, oracle-xe is a longshot as it is not run at boot.

Don't worry about attaching oracle-xe if it's normally disabled.

Looking at comment 5, it's now setting the hostname to ftglap from dhcp,
and not changing it back to localhost.

So it's now working properly without /etc/hostname having the localhost
setting? That file is owned by systemd, so the problem appears to be being
caused by /etc/hostname sometimes overriding the dhcp returned hostname.

Can you confirm that putting /etc/hostname back with
"urpmi --replacepkgs --replacefiles systemd" is what's over riding the
dhcp supplied hostname?

Yep, I'll try that tomorrow.

And yes, it is working properly without an /etc/hostname file.  This holds even across a reboot, so the /etc/hostname isn't being recreated by, say, harddrake2.

The problem may not be that /etc/hostname is overriding DHCP but more that if systemd.hostnamed is installed then /etc/hostname shouldn't be created or shouldn't contain "localhost", as that appears to cause the hostnamed daemon to reset the hostname to "localhost" whenever it detects that it has changed.

Or, it may be simply that systemd.network and NM can't be active at the same time, just as NM and net-applet can't be.

Running urpmi as above recreates the /etc/hostname file containing "localhost", and rebooting restores the behavior described above, resetting the hostname to localhost.

Please try "systemctl disable systemd-networkd.service", reboot, and see if
the problem persists.

If that still fails, try "systemctl mask systemd-networkd.service".

Both commands complete successfully but neither one prevents the hostname override.  If this didn't keep happening every time NM sets the correct hostname from DHCP I'd suspect some legacy piece of Unix/Linux which reacts to the presence of /etc/hostname, and it's just bad luck that systemd creates one.  But whatever the daemon is, it reacts faster than msec would.

However, according to this https://www.freedesktop.org/software/systemd/man/hostname.html if /etc/hostname exists it will trump DHCP.

According to the journalctl output, systemd sets the hostname to "the default" (localhost) before NM ever comes into the picture, so the problem appears to be that the systemd install creates an /etc/hostname containing "localhost".  This isn't necessary (because systemd will do that anyway).  But the presence of this file causes hostnamed to reset the hostname whenever it is changed by something else, e. g. NM.  The /etc/hostname file should simply not be created by the rpm.

Again:

"localhost" and "localhost.localdomain" are not suitable for a network-connected computer. You must add a specific hostname to your machine, or let's DHCP server to attribute one.

localhost must refer to link-local 127.0.0.1 or ::1 (IPv6) and for un-networked machines. For example, 192.168.1.22 should not be localhost.

But, this bug seems to involve networkmanager and systemd-hostnamed who race to attribute one. Anyway, to prevent such undesired behaviour, please attribute a valid and unique hostname to your computer like frank.local if you don't have a real fully qualified domain name.

Also, /etc/hostname file must be owned by a package, currently it is
$ urpmf -f /etc/hostname
systemd-246.13-1.mga8.x86_64:/etc/hostname

Why it does not let NetworkManager to modify it a

Assignee: bugsquad => basesystem
CC: (none) => ouaurelien

Hum.... continuing Comment 14:

Assigning to basesystem.

Why systemd-hostnamed does not let NetworkManager to modify host hostname at runtime?
Seems a systemd bug or a wrong NM configuration?

Does this also apply to Mageia 8?

Source RPM: systemd => systemd-248-2.mga9.src.rpm

The name "hostnamed" suggests a daemon, and the only purpose to have a daemon setting the hostname rather than one-time code during init or systemd is if you want hostnamed to reset the hostname whenever it changes.  Why this would be desirable I can't begin to imagine.

But, as I say, since systemd without /etc/hostname sets the hostname initially to localhost anyway (and doesn't mess with it afterwards), there is no point to creating an /etc/hostname containing "localhost".

On my systems, I run everything from DHCP including setting the hostname and registering the hostname in my local DNS.  Also, anything trying to obtain an IP address from my DHCP server will fail unless the MAC of the NIC has been registered in my /etc/dhcpd.conf.

As systemd-hostnamed.service is a static service disabling it does not prevent
it from running.

If network manager is being used, the systemd service should be masked, as in ...
systemctl mask systemd-hostnamed.service

That's a much easier fix then finding all of the scripts or programs that
may fail if /etc/hostname does not exist.

Dave, I tried the mask command and it had no effect (see comment#12).

I went to an older cauldron system which does not have this problem, and found that /etc/hostname exists there and contains "localhost".  The difference is that on that system there is no hostnamed.service unit.  So I think the key to the mystery is why hostnamed was added.

According to the hostnamed.service manpage:

=======================================================================
It currently offers access to five variables:

•The current hostname (Example: "dhcp-192-168-47-11")

•The static (configured) hostname (Example: "lennarts-computer")

•The pretty hostname (Example: "Lennart's Computer")

•A suitable icon name for the local host (Example: "computer-laptop")

•A chassis type (Example: "tablet")

=======================================================================

This implies that hostnamed leaves a changed hostname (the "current hostname" intact unless it is told to reset it, which suggests that something else in the system is telling it to reset it.

systemd v248 has learned new tricks, and I think some is still somewhat WIP... so I do expect some bugs... and this is Cauldron, so some hiccups are expected...

From:
https://systemd-devel.freedesktop.narkive.com/tEHAUEDR/systemd-248-released

* When the hostname is set explicitly to "localhost", systemd-hostnamed
will respect this. Previously such a setting would be mostly silently
ignored. The goal is to honour configuration as specified by the
user.

* The fallback hostname that will be used by the system manager and
systemd-hostnamed can now be configured in two new ways: by setting
DEFAULT_HOSTNAME= in os-release(5), or by setting
$SYSTEMD_DEFAULT_HOSTNAME in the environment block. As before, it can
also be configured during compilation. The environment variable is
intended for testing and local overrides, the os-release(5) field is
intended to allow customization by different variants of a
distribution that share the same compiled packages.

* systemd-hostnamed now exports the default hostname and the source of
the configured hostname ("static", "transient", or "default") as
D-Bus properties.

* systemd-hostnamed now exports the "HardwareVendor" and
"HardwareModel" D-Bus properties, which are supposed to contain a
pair of cleaned up, human readable strings describing the system's
vendor and model. It's typically sourced from the firmware's DMI
tables, but may be augmented from a new hwdb database. hostnamectl
shows this in the status output.




And I also guess NetworkManager has not yet learned how to play nice with systemd bits...

I don't think this has anything to do with NM itself, just that NM happens to be the DHCP agent that sets the DHCP hostname and detects that it has been changed.

It looks to me like something is monitoring the D-Bus hostname properties and changing the current hostname back to the static one.

yeah, I meant that the interaction between systemd <-> networkmanager is not fully working...

Here's an interesting thing.  If I use "hostnamectl" on the older system, I get:

[ftg@ftgme2 ~]$ hostnamectl
   Static hostname: localhost
Transient hostname: ftgme2
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: 85dd3ec8bfc84a4ea25b840ba0334036
           Boot ID: cd1174d420c6458eb401126ad9cd9d4a
  Operating System: Mageia 8
            Kernel: Linux 5.7.12-desktop-1.mga8
      Architecture: x86-64
[ftg@ftgme2 ~]$ 

but if I do it in current cauldron I get:

[root@localhost ~]# hostnamectl
 Static hostname: localhost
       Icon name: computer-laptop
         Chassis: laptop
      Machine ID: b04d9075ef2140d783a8a852fe593fce
         Boot ID: 640f542a58ce4356b76527ac2a6745ce
Operating System: Mageia 9
          Kernel: Linux 5.11.15-desktop-1.mga9
    Architecture: x86-64
 Hardware Vendor: ASUSTeK COMPUTER INC.
  Hardware Model: VivoBook_ASUSLaptop X532FLC_S532FL
[root@localhost ~]# 

i. e. 248 is not recording the transient (DHCP-assigned) hostname.

As it turns out, the "change in behaviour" is intended as this landed in v248-rc1:
https://github.com/systemd/systemd/commit/d39079fcaa05e23540d2b1f0270fa31c22a7e9f1

so basically the "fix" for now is as you did... "nuke /etc/hostname" if you dont want a static configured name

I sort of have to agree as "localhost" is not a good hostname (even if it always should resolv / point to 127.0.0.1 and ::1

We need to fix the installer regarding hostname handling

I read the comment at that link, but it basically says that if someone provides an /etc/hostname containing "localhost" it should be honored.  That doesn't explain why systemd should provide such a file at all.  That should be the job of whatever application configures the network *if* the user wants a static hostname.

because it's working as designed from a time when stuff would break if no /etc/hostname was/is available, and no-one has actully audited if that is still the case... 

and yes, many (most) people still like a static hostname...


so systemd own the file as %ghost, so it can be absent...

and systemd keeps it in sync at install/upgrade with network config in sysconfig:

hostname_new=`cat %_sysconfdir/hostname 2>/dev/null`
if [ -z $hostname_new ]; then
        hostname_old=`cat /etc/sysconfig/network 2>/dev/null | grep HOSTNAME | cut -d "=" -f2`
        if [ ! -z $hostname_old ]; then
                echo $hostname_old >> %_sysconfdir/hostname
        else
                echo "localhost" >> %_sysconfdir/hostname
        fi
fi

as a first step to test and flush out any issues with nothing in /etc/hostname I will probably disable the "else" bit that adds localhost if nothing is found elsewhere...

Ping ?

Right now my workaround is to edit /etc/hostname, delete the localhost line, save it, and then chattr the file to immutable.

Ping again.  This is still happening in current cauldron.

Anything happening here ?  Unfortunately, even with "chattr -i /etc/hostname", the file gets recreated periodically when "urpmi --auto-update" affects systemd.  Any idea why systemd updates should override "chattr -i" ?