Bug 974811 - NetworkManager dispatchers dbus services misconfiguration
Summary: NetworkManager dispatchers dbus services misconfiguration
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
(Show other bugs)
Version: 20
Hardware: Unspecified Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Winship
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Keywords: Reopened
: 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, RCNTEC Ltd
Modified: 2015-06-30 00:39 UTC (History)
31 users (show)

Fixed In Version: NetworkManager-0.9.8.2-9.git20130709.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-30 00:39:32 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

Description Artemy Kapitula, RCNTEC Ltd 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.


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