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.