Yes, I hit the same problem on an f18->f19 upgrade. It looks like the NetworkManager package is what ships the NetworkManager-dispatcher.service file. It seems like it should include dbus-org.freedesktop.nm-dispatcher.service.

I'll also note that the package includes this file as well:

    /usr/share/dbus-1/system-services/org.freedesktop.nm_dispatcher.service

...so maybe it's just a matter of confusion between '-' and '_' in the name?

Proposed as a Blocker for 19-final by Fedora user thozza using the blocker tracking app because:

 Bug #974811 blocks NM dispatcher from running at all. It breaks also dnssec-trigger functionality, since it uses NM dispatcher script. dnssec-trigger together with unbound is used for DNSSEC validation on workstations on Fedora since F18.

https://bugzilla.redhat.com/show_bug.cgi?id=971650
Seems related, but not sure if it's a duplicate.

NetworkManager-dispatcher.service is a new service name. But it has not been added to the default fedora preset policy. Thus the dispatcher service was not enabled.
I've filed bug 977433 to fix that.

Discussed at 2013-06-24 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-24/f19final-blocker-review-8.2013-06-24-16.00.log.txt . As we understand this issue, it's rejected as a blocker: it does not seem to involve any critpath function and could be reasonably well addressed with a post-release update. But we agreed to accept it as a freeze exception issue as there may be some use of dnssec on the live images, so long as any fix is very simple. A systemd update which *only* added a preset to address this bug may be considered. Any more complex change, especially to NetworkManager or systemd, is unlikely to go through at this point.

*** Bug 979684 has been marked as a duplicate of this bug. ***

I updated to systemd-204-9 and was still getting the same error. After manually running 'systemctl enable NetworkManager-dispatcher.service' it works. Is that expected — is this something that all beta users are going to have to fix manually, but those installing (or upgrading to) the real F19 will be fine?

Bug 977433 got fixed as a 0-day update. The fix consists merely of the change in the preset file. Installing the update does not automatically re-enable the service if it is already installed and disabled. So yes, if one is already affected, the manual action is needed.

I wonder if it's really helpful that NetworkManager-dispatcher.service's DBus activation is allowed to be disabled. To me the cases where users might want to disable it seem pretty rare. If it really is an exceptional case, maybe it should only be possible to do it via unit masking.

So *anyone* who installs F19 without updates, and then updates after the installation, will find this broken?

Perhaps an updated package should have a %post script which enables it?

If, as you say, there's no real reason for disabling it, then it's not entirely unsafe to assume that if it's disabled then that's *just* because of this bug...

I have update from f18, and I have this problem.

Confirm: I have do 'systemctl enable NetworkManager-dispatcher.service' and now all work fine.


I use NetworkManager-0.9.8.2-5.fc19.x86_64

*** Bug 985385 has been marked as a duplicate of this bug. ***

I did a fresh install of F19 x86_64 a few days ago and just spent a good half an hour trying to figure out why dhcpd is having start up issues.  I tried systemctl enable NetworkManager-wait-online.service, but that didn't help because while it delayed the dhcpd start up until after the external interface was configured, dhcpd still managed to start before the internal interface was configured (1#$@$#%@ fast systems :-).  I had some memory of hacking up scripts to restart dhcpd whenever an interface changed, so I went back through my build instructions for earlier versions of Fedora and found NetworkManager scripts I was using in Fedora 14.  Yay for writing extensive docs and keeping them around  indefinitely!

Then I noticed that there was already a /etc/NetworkManager/dispatcher.d/12-dhcpd and was really confused why it wasn't helping.  After a lot of poking, I seem to have figured out that nothing in this directory is running!  Sure enough, I need to enable NetworkManager-dispatcher.service!  Now everything works!

<rolls eyes>

Have same bug after yesterday's updates on Fedora 18! (some of updated packages are listed below)
Workaround by Artemy still works on F18, so we can say that the bug ported successfully. ;)

Aug 15 15:11:32 Updated: 1:NetworkManager-glib-0.9.8.2-1.fc18.x86_64
Aug 15 15:11:34 Updated: libnm-gtk-0.9.8.2-1.fc18.x86_64
Aug 15 15:12:08 Updated: nm-connection-editor-0.9.8.2-1.fc18.x86_64
Aug 15 15:12:16 Updated: 1:NetworkManager-0.9.8.2-1.fc18.x86_64

Dan, can you take a look at this?  I guess we just need to unconditionally enable the dispatcher systemd service in %post for now, users that don't want it can mask it I suppose.

Created attachment 796924 [details]
patch

so, just this?

and am I correct in thinking that we only need this for F19, not F20/rawhide

Couldn't this be solved in upstream side to not need to workaround it enabling the service manually? The upstream bug is unattended for some time, then, I am unsure if we are supposed to enable the service manually or try to fix it in other way :/

Thanks for the info :)

what upstream bug are you referring to?

Finally was able to find it
https://bugzilla.gnome.org/show_bug.cgi?id=702341

(In reply to Dan Winship from comment #15)
> Created attachment 796924 [details]
> patch
> 
> so, just this?

Hmm, actually, I just looked at /usr/lib/systemd/system-preset/90-default.preset on F19, and it includes the dispatcher as enabled.  But it's already in the %systemd_post line, so I'm not really sure what's going on here.  If the %systemd_post is being used, then I'd expect that it would be enabled already?  Need to get some systemd people involved here I guess.

Michal, any idea about this?  The Dispatcher is already in %systemd_post, so shouldn't that enable the service by default given the F19 presets?

I'm on F19 now.

$ sudo systemctl status dbus-org.freedesktop.nm-dispatcher.service
dbus-org.freedesktop.nm-dispatcher.service
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)

$ sudo systemctl status NetworkManager-dispatcher.service
NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager-dispatcher.service; disabled)
   Active: inactive (dead)

Created attachment 799350 [details]
[PATCH] only enable NM dispatcher when upgrading to the newer version

(In reply to Dan Winship from comment #15)
> Created attachment 796924 [details]
> patch
> 
> so, just this?
> and am I correct in thinking that we only need this for F19, not F20/rawhide
> 

Yeah, F19 should be sufficient, because for F20/rawhide the preset file has been  corrected meanwhile.
We may want to enable the dispatcher conditionally, only once when upgrading from old version. That way we won't keep enabling it on further updates (had any user decided to disable it intentionally).

(In reply to Dan Williams from comment #19)
> Hmm, actually, I just looked at
> /usr/lib/systemd/system-preset/90-default.preset on F19, and it includes the
> dispatcher as enabled.  But it's already in the %systemd_post line, so I'm
> not really sure what's going on here.  If the %systemd_post is being used,
> then I'd expect that it would be enabled already?  Need to get some systemd
> people involved here I guess.
> 
> Michal, any idea about this?  The Dispatcher is already in %systemd_post, so
> shouldn't that enable the service by default given the F19 presets?

We filed a request for correcting the dispatcher name in 90-default.preset late. So it was not enabled for F19 users on initial installation. And the preset is *not* used on updates (because it would reset user's possible manual change).
%systemd_post is defined on F19 in /etc/rpm/macros.systemd as:
%systemd_post()
if [ $1 -eq 1 ] ; then \
    # Initial installation \
    /usr/bin/systemctl preset %{?*} >/dev/null 2>&1 || : \
#fi \
%{nil}

Jirka's explanation is correct. Clearing needinfo.

(In reply to Jirka Klimes from comment #21)
> Created attachment 799350 [details]
> [PATCH] only enable NM dispatcher when upgrading to the newer version

looks good to me

Looks good to me too.

NetworkManager-0.9.8.2-9.git20130709.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.8.2-9.git20130709.fc19

Package NetworkManager-0.9.8.2-9.git20130709.fc19:
* should fix your issue,
* was pushed to the Fedora 19 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.8.2-9.git20130709.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-17625/NetworkManager-0.9.8.2-9.git20130709.fc19
then log in and leave karma (feedback).

NetworkManager-0.9.8.2-9.git20130709.fc19 seems to work here..

NetworkManager-0.9.8.2-9.git20130709.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

I still have the same issue with  NetworkManager 1:0.9.9.0-20.git20131003.fc20

1:0.9.9.0-22.git20131003.fc20

systemctl status NetworkManager-dispatcher.service
NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager-dispatcher.service; disabled)
   Active: inactive (dead)



systemctl status dbus-org.freedesktop.nm-dispatcher.service
dbus-org.freedesktop.nm-dispatcher.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

NetworkManager[516]: nm_platform_ip6_address_add: assertion 'lifetime > 0' failed

Although it's probably too late for this to make any difference, I would like to point out that the solution to this bug didn't help me.  During January 2014 (well after the resolution had been applied) I upgraded directly from Fedora 18 to Fedora 20.  NetworkManager-dispatcher.service was not automatically enabled.

People, please remember that not everyone installs every Fedora release in sequence.

*** Bug 1087883 has been marked as a duplicate of this bug. ***

Same here, I did fedup from Fedora 18 to Fedora 20 (with updates enabled during the fedup) last week and it left the NetworkManager-dispatcher.service disabled.  Is it possible to provide an automatic solution for users who upgrade?

(In reply to Alan Stern from comment #31)
> Although it's probably too late for this to make any difference, I would
> like to point out that the solution to this bug didn't help me.  During
> January 2014 (well after the resolution had been applied) I upgraded
> directly from Fedora 18 to Fedora 20.  NetworkManager-dispatcher.service was
> not automatically enabled.
> 
> People, please remember that not everyone installs every Fedora release in
> sequence.

I do it this 
https://bbs.archlinux.org/viewtopic.php?id=173068

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Just saw this when upgrading from F33 to F34.

Uh, that seems unlikely...what exactly did you see?

I'm using the following script of /etc/NetworkManager/dispatcher.d/hostname.sh and getting the following logging (filtered for things like systemd and audit being excluded, and unrelated services like proftpd):

Nov  8 15:57:35 localhost /usr/sbin/irqbalance[840]: libcap-ng used by "/usr/sbin/irqbalance" failed due to not having CAP_SETPCAP in capng_apply
Nov  8 15:57:35 localhost rsyslogd[854]: [origin software="rsyslogd" swVersion="8.2102.0-3.fc34" x-pid="854" x-info="https://www.rsyslog.com"] start
Nov  8 15:57:35 localhost systemd-resolved[800]: Defaulting to hostname 'fedora'.
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.0915] NetworkManager (version 1.30.6-1.fc34) is starting... (for the first time)
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.0915] Read config: /etc/NetworkManager/NetworkManager.conf
Nov  8 15:57:35 localhost ip6tables.init[831]: ip6tables: Applying firewall rules: [  OK  ]
Nov  8 15:57:35 localhost ip6tables.init[831]: ip6tables: Loading additional modules: nf_conntrack_ftp nf_conntrack_tftp [  OK  ]
Nov  8 15:57:35 localhost systemd-logind[867]: New seat seat0.
Nov  8 15:57:35 localhost systemd-logind[867]: Watching system buttons on /dev/input/event0 (Power Button)
Nov  8 15:57:35 localhost systemd-logind[867]: Watching system buttons on /dev/input/event1 (AT Translated Set 2 keyboard)
Nov  8 15:57:35 localhost journal[871]: Ready
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.3039] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.3148] manager[0x56356e123030]: monitoring kernel firmware directory '/lib/firmware'.
Nov  8 15:57:35 localhost journal[908]: failed to get edid data: EDID length is too small
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8153] hostname: hostname: using hostnamed
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8155] hostname: hostname changed from (none) to "localhost.localdomain"
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8162] dns-mgr[0x56356e117170]: init: dns=default,systemd-resolved rc-manager=symlink (auto)
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8683] manager[0x56356e123030]: rfkill: Wi-Fi hardware radio set enabled
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8684] manager[0x56356e123030]: rfkill: WWAN hardware radio set enabled
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8770] manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8774] manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8776] manager: Networking is enabled by state file
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8789] dhcp-init: Using DHCP client 'dhclient'
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8807] settings: Loaded settings plugin: keyfile (internal)
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8852] settings: Loaded settings plugin: ifcfg-rh ("/usr/lib64/NetworkManager/1.30.6-1.fc34/libnm-settings-plugin-ifcfg-rh.so")
Nov  8 15:57:35 localhost nm-dispatcher[931]: req:1 'hostname': new request (6 scripts)
Nov  8 15:57:35 localhost nm-dispatcher[931]: req:1 'hostname': start running ordered scripts...
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.9364] device (lo): carrier: link connected
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.9411] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/1)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412255.9498] manager: (ens3): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
Nov  8 15:57:36 localhost kernel: igbvf 0000:00:03.0: Link is Up 1000 Mbps Full Duplex
Nov  8 15:57:36 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): ens3: link becomes ready
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412255.9597] device (ens3): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:2 'connectivity-change': new request (6 scripts)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.0504] device (ens3): carrier: link connected
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.0834] device (ens3): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost iptables.init[836]: iptables: Applying firewall rules: [  OK  ]
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1123] policy: auto-activating connection 'System ens3' (db7b64ba-a781-4456-8a0f-9d41a8e8904b)
Nov  8 15:57:36 localhost iptables.init[836]: iptables: Loading additional modules: nf_conntrack_ftp nf_conntrack_tftp [  OK  ]
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1181] device (ens3): Activation: starting connection 'System ens3' (db7b64ba-a781-4456-8a0f-9d41a8e8904b)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1185] device (ens3): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1281] manager: NetworkManager state is now CONNECTING
Nov  8 15:57:36 localhost hostname.sh[948]: hostname: localhost.localdomain
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1332] device (ens3): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:2 'connectivity-change': start running ordered scripts...
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1511] device (ens3): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1569] dhcp4 (ens3): activation: beginning transaction (timeout in 45 seconds)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.1660] dhcp4 (ens3): dhclient started with pid 953
Nov  8 15:57:36 localhost dhclient[953]: DHCPREQUEST for 192.168.4.3 on ens3 to 255.255.255.255 port 67 (xid=0x475a9242)
Nov  8 15:57:36 localhost dhclient[953]: DHCPACK of 192.168.4.3 from 192.168.4.1 (xid=0x475a9242)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2685] dhcp4 (ens3):   address 192.168.4.3
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   plen 24 (255.255.255.0)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   gateway 192.168.4.1
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   lease time 43200
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   hostname 'mail'
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   nameserver '192.168.4.1'
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   domain name 'redfish-solutions.com'
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp (ens3):   domain search 'redfish-solutions.com.'
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp (ens3):   domain search 'redfish-consulting.com.'
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2689] dhcp4 (ens3): state changed unknown -> extended, address=192.168.4.3
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2752] device (ens3): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:3 'pre-up' [ens3]: new request (0 scripts)
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:3 'pre-up' [ens3]: completed: no scripts
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2921] device (ens3): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2923] device (ens3): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2928] manager: NetworkManager state is now CONNECTED_LOCAL
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3059] manager: NetworkManager state is now CONNECTED_SITE
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3063] policy: set 'System ens3' (ens3) as default for IPv4 routing and DNS
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3070] policy: set-hostname: set hostname to 'mail' (from DHCPv4)
Nov  8 15:57:36 localhost systemd-resolved[800]: ens3: Bus client set search domain list to: redfish-solutions.com, redfish-consulting.com
Nov  8 15:57:36 localhost systemd-resolved[800]: ens3: Bus client set default route setting: yes
Nov  8 15:57:36 localhost systemd-resolved[800]: ens3: Bus client set DNS server list to: 192.168.4.1
Nov  8 15:57:36 localhost dhclient[953]: bound to 192.168.4.3 -- renewal in 19936 seconds.
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3361] device (ens3): Activation: successful, device activated.
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3371] manager: NetworkManager state is now CONNECTED_GLOBAL
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:4 'up' [ens3]: new request (6 scripts)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3386] manager: startup complete
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:4 'up' [ens3]: start running ordered scripts...
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:5 'connectivity-change': new request (6 scripts)
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:6 'hostname': new request (6 scripts)
Nov  8 15:57:36 localhost 11-dhclient[996]: Would have set domainname redfish-solutions.com
Nov  8 15:57:36 localhost hostname.sh[1010]: up: mail.redfish-solutions.com
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:5 'connectivity-change': start running ordered scripts...
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:6 'hostname': start running ordered scripts...
Nov  8 15:57:36 localhost hostname.sh[1040]: hostname: localhost.localdomain
Nov  8 15:57:37 localhost httpd[985]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain. Set the 'ServerName' directive globally to suppress this message
Nov  8 15:57:37 localhost httpd[985]: Server configured, listening on: port 443, port 80
Nov  8 15:57:37 localhost rsyslogd[854]: imjournal: journal files changed, reloading...  [v8.2102.0-3.fc34 try https://www.rsyslog.com/e/0 ]
Nov  8 15:57:39 localhost dbus-daemon[1306]: [session uid=1000 pid=1304] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=1000 pid=1307 comm="systemctl --user import-environment DISPLAY XAUTHO" label="system_u:system_r:unconfined_service_t:s0")
Nov  8 15:57:39 localhost dbus-daemon[1306]: [session uid=1000 pid=1304] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1
Nov  8 15:57:40 localhost check[898]: prefork: child states: II
Nov  8 15:58:40 localhost systemd-logind[867]: New session 1 of user root.
Nov  8 15:59:15 localhost setroubleshoot[1368]: SELinux is preventing systemd from remove_name access on the directory localhost.localdomain:2.pid. For complete SELinux messages run: sealert -l 92f33fbf-91c5-4950-a7b3-b42e8845cc68
Nov  8 15:59:15 localhost setroubleshoot[1368]: SELinux is preventing systemd from remove_name access on the directory localhost.localdomain:2.pid.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that systemd should be allowed remove_name access on the localhost.localdomain:2.pid directory by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'systemd' --raw | audit2allow -M my-systemd#012# semodule -X 300 -i my-systemd.pp#012



The lines that I find interesting are:

Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8153] hostname: hostname: using hostnamed
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8155] hostname: hostname changed from (none) to "localhost.localdomain"
...
Nov  8 15:57:35 localhost NetworkManager[821]: <info>  [1636412255.8789] dhcp-init: Using DHCP client 'dhclient'
...
Nov  8 15:57:35 localhost nm-dispatcher[931]: req:1 'hostname': new request (6 scripts)
Nov  8 15:57:35 localhost nm-dispatcher[931]: req:1 'hostname': start running ordered scripts...
...
Nov  8 15:57:36 localhost hostname.sh[948]: hostname: localhost.localdomain            <<<<< from dispatcher.d/hostname.sh
...
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   hostname 'mail'
...
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.2686] dhcp4 (ens3):   domain name 'redfish-solutions.com'
...
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3070] policy: set-hostname: set hostname to 'mail' (from DHCPv4)       <<<<< should be set to what we want, right?  but it's not...
...
Nov  8 15:57:36 localhost dhclient[953]: bound to 192.168.4.3 -- renewal in 19936 seconds.
...
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3371] manager: NetworkManager state is now CONNECTED_GLOBAL
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:4 'up' [ens3]: new request (6 scripts)
Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3386] manager: startup complete
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:4 'up' [ens3]: start running ordered scripts...
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:5 'connectivity-change': new request (6 scripts)
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:6 'hostname': new request (6 scripts)
Nov  8 15:57:36 localhost hostname.sh[1010]: up: mail.redfish-solutions.com                <<<<< from dispatcher.d/hostname.sh showing "${DHCP4_HOST_NAME}.${DHCP4_DOMAIN_NAME}" with correctly provisioned values from DHCP server
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:5 'connectivity-change': start running ordered scripts...
Nov  8 15:57:36 localhost nm-dispatcher[931]: req:6 'hostname': start running ordered scripts...
Nov  8 15:57:36 localhost hostname.sh[1040]: hostname: localhost.localdomain                   <<<<< from dispatcher.d/hostname.sh


Those last 2 lines from /etc/NetworkManager/dispatcher.d/hostname.sh are what's interesting.

Created attachment 1840770 [details]
dispatcher.d script for NM

If I uncomment these lines:


case "$ACTION" in
...

up)
    log "up: ${DHCP4_HOST_NAME}.${DHCP4_DOMAIN_NAME}"
    # hostname "${DHCP4_HOST_NAME}"
    # domainname "${DHCP4_DOMAIN_NAME}"
    ;;
esac


then the system boots and functions correctly, but why is this site-specific localization even necessary?  This is what's supposed to happen out-of-the-box, right?

It tells me it's doing:

Nov  8 15:57:36 localhost NetworkManager[821]: <info>  [1636412256.3070] policy: set-hostname: set hostname to 'mail' (from DHCPv4)

but it isn't actually.  Also, what happens to option 15 (domain name)?

So this bug is definitely not about NetworkManager not setting the hostname to the value received via DHCP. Please file a new bug for that. It does seem to me like it's *supposed* to do that (though there's a distinction between static and transient hostnames which may be tripping us up here).

This bug is about NetworkManager-dispatcher.service not being enabled by default, which you say was the case for you, but it was about a specific issue that caused this around the F18-F20 timeframe, and that specific issue was definitely resolved. You say you installed as F24, which is after this stuff happened. I'd say file a new bug for that too, but honestly, I'm not sure we'd be able to track it down for a system which was upgraded from F24 to now. I did check that the service is definitely enabled by default for fresh installs:

$ grep dispatcher /usr/lib/systemd/system-preset/*
/usr/lib/systemd/system-preset/90-default.preset:enable NetworkManager-dispatcher.service

See https://bugzilla.redhat.com/show_bug.cgi?id=2021363

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Since Philip opened a new bug that got some follow-up, I think we can close this again.