Bug 974811 - NetworkManager dispatchers dbus services misconfiguration
Summary: NetworkManager dispatchers dbus services misconfiguration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 34
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Winship
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 979684 985385 1087883 (view as bug list)
Depends On: 977433
Blocks: F19-accepted, F19FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2013-06-16 04:27 UTC by Artemy Kapitula, Mail.Ru Cloud Solutions
Modified: 2022-05-13 23:30 UTC (History)
31 users (show)

Fixed In Version: NetworkManager-0.9.8.2-9.git20130709.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-13 23:30:56 UTC
Type: Bug


Attachments (Terms of Use)
patch (1.46 KB, patch)
2013-09-12 16:13 UTC, Dan Winship
no flags Details | Diff
[PATCH] only enable NM dispatcher when upgrading to the newer version (827 bytes, patch)
2013-09-18 12:31 UTC, Jirka Klimes
no flags Details | Diff
dispatcher.d script for NM (607 bytes, text/plain)
2021-11-08 23:41 UTC, Philip Prindeville
no flags Details

Description Artemy Kapitula, Mail.Ru Cloud Solutions 2013-06-16 04:27:08 UTC
Description of problem:

NM "dispatchers" doesn't work in Fedora 19.

Version-Release number of selected component (if applicable):

NetworkManager-0.9.8.2-1.fc19.x86_64

How reproducible:

Always

Steps to Reproduce:

Create any executable script in /et/NetworkManager/dispatcher.d
Deactivate and activate again any network connection.

Actual results:

Dispatcher script didn't executed

Expected results:

Dispatcher script must be executed.

Additional info:

The message found in /var/log/messages:
Activation via systemd failed for unit
    'dbus-org.freedesktop.nm-dispatcher.service':
     Unit dbus-org.freedesktop.nm-dispatcher.service
     failed to load: No such file or directory. See system logs and 
    'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details

The workaround is a symlink
   /usr/lib/systemd/system/dbus-org.freedesktop.nm-dispatcher.service ->
      /usr/lib/systemd/system/NetworkManager-dispatcher.service
solves problem

Comment 1 Jeff Layton 2013-06-18 10:54:12 UTC
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?

Comment 2 Fedora Blocker Bugs Application 2013-06-24 07:07:51 UTC
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.

Comment 3 hannes 2013-06-24 07:34:32 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=971650
Seems related, but not sure if it's a duplicate.

Comment 4 Jirka Klimes 2013-06-24 14:32:03 UTC
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.

Comment 5 Adam Williamson 2013-06-24 16:24:04 UTC
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.

Comment 6 Jirka Klimes 2013-07-01 08:35:20 UTC
*** Bug 979684 has been marked as a duplicate of this bug. ***

Comment 7 David Woodhouse 2013-07-02 13:00:27 UTC
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?

Comment 8 Michal Schmidt 2013-07-02 13:57:14 UTC
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.

Comment 9 David Woodhouse 2013-07-02 14:30:19 UTC
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...

Comment 10 Dario Lesca 2013-07-12 08:09:11 UTC
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

Comment 11 Jirka Klimes 2013-07-19 10:14:25 UTC
*** Bug 985385 has been marked as a duplicate of this bug. ***

Comment 12 Toby Ovod-Everett 2013-07-22 00:10:41 UTC
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>

Comment 13 pavel.nedr 2013-08-16 04:49:34 UTC
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

Comment 14 Dan Williams 2013-08-16 16:50:16 UTC
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.

Comment 15 Dan Winship 2013-09-12 16:13:01 UTC
Created attachment 796924 [details]
patch

so, just this?

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

Comment 16 Pacho Ramos 2013-09-12 18:19:37 UTC
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 :)

Comment 17 Dan Winship 2013-09-12 18:26:01 UTC
what upstream bug are you referring to?

Comment 18 Pacho Ramos 2013-09-12 18:46:54 UTC
Finally was able to find it
https://bugzilla.gnome.org/show_bug.cgi?id=702341

Comment 19 Dan Williams 2013-09-17 14:51:05 UTC
(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?

Comment 20 pavel.nedr 2013-09-17 19:32:49 UTC
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)

Comment 21 Jirka Klimes 2013-09-18 12:31:23 UTC
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}

Comment 22 Michal Schmidt 2013-09-18 15:51:02 UTC
Jirka's explanation is correct. Clearing needinfo.

Comment 23 Dan Winship 2013-09-23 13:23:14 UTC
(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

Comment 24 Dan Williams 2013-09-24 15:50:12 UTC
Looks good to me too.

Comment 25 Fedora Update System 2013-09-24 16:09:04 UTC
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

Comment 26 Fedora Update System 2013-09-26 06:09:44 UTC
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).

Comment 27 Steve 2013-09-27 08:57:53 UTC
NetworkManager-0.9.8.2-9.git20130709.fc19 seems to work here..

Comment 28 Fedora Update System 2013-09-28 00:23:20 UTC
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.

Comment 29 Filipe Azevedo 2013-12-18 20:41:28 UTC
I still have the same issue with  NetworkManager 1:0.9.9.0-20.git20131003.fc20

Comment 30 gr88gxp 2014-01-03 05:55:46 UTC
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

Comment 31 Alan Stern 2014-03-10 18:16:47 UTC
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.

Comment 32 Charles R. Anderson 2014-04-16 02:01:09 UTC
*** Bug 1087883 has been marked as a duplicate of this bug. ***

Comment 33 Charles R. Anderson 2014-04-16 02:08:06 UTC
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.

Comment 34 anagganalani 2014-10-27 14:33:37 UTC
I do it this 
https://bbs.archlinux.org/viewtopic.php?id=173068

Comment 35 Fedora End Of Life 2015-05-29 09:07:31 UTC
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.

Comment 36 Fedora End Of Life 2015-06-30 00:39:32 UTC
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.

Comment 37 Philip Prindeville 2021-11-06 20:08:10 UTC
Just saw this when upgrading from F33 to F34.

Comment 38 Adam Williamson 2021-11-07 06:32:30 UTC
Uh, that seems unlikely...what exactly did you see?

Comment 39 Philip Prindeville 2021-11-08 23:39:13 UTC
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.

Comment 40 Philip Prindeville 2021-11-08 23:41:30 UTC
Created attachment 1840770 [details]
dispatcher.d script for NM

Comment 41 Philip Prindeville 2021-11-08 23:48:18 UTC
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)?

Comment 42 Adam Williamson 2021-11-09 00:13:30 UTC
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

Comment 43 Philip Prindeville 2021-11-09 00:43:18 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=2021363

Comment 44 Ben Cotton 2022-05-12 15:03:26 UTC
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.

Comment 45 Adam Williamson 2022-05-13 23:30:56 UTC
Since Philip opened a new bug that got some follow-up, I think we can close this again.


Note You need to log in before you can comment on or make changes to this bug.