Bug 477964

I also get this problem, except I use Fedora 9, and the problem occurs when I resume from hibernation.  Otherwise it is exactly as described above.  I have been hibernating my laptop for more than a year every night, and this problem has only appeared recently.  At the moment, I am only using a wired connection.

I am using the following components:
kernel-2.6.27.9-73.fc9.i686
NetworkManager-0.7.0-0.12.svn4326.fc9.i386
gnome-power-manager-2.22.1-1.fc9.i386
dbus-1.2.4-2.fc9.i386

Still present in NetworkManager-0.7.0-1.git20090102.fc10.x86_64.

Can you attach some logs from /var/log/messages showing a suspend/resume cycle where this happens?

Here it comes from tomorrow morning.
(note that all gaps are due to a slow syncing cisco switch and our dhcp server being a little lazy)

I had a look over the code with that log and one from a successfull run. The only difference I could see so far was that null in the first dhcp message.
It seems that everything else runs fine. Maybe thats all just a nm-applet race condition on wakeup. I'll use ifconfig the next time it hits me to see, if NetworkManager runs fine in background.

Created attachment 328535 [details]
nm log with "disabled network bug"

Created attachment 328620 [details]
NM log when all networking disabled

I've attached mine above. The system started off working on wired (r8169), was then suspended, and resumed at home with no network cable plugged in, but in the presence of my wireless network.

I had the same issue again this morning and this time had a look at my log files _before_ I reactivated NM. I can confirm that the "Waking up" message never appears. Which would mean that it's not NM's fault at all. Instead the process which should send the "Sleep" dbus message (or dbus itself) is buggy.
So, what process is in charge of this (I've seen a lot of distribution specific scripts in some /etc/* folders in the past, but what does f9 do?)? And how can I bring dbus to log all messages that go to org.freedesktop.NetworkManager?

Look in the pm-utils package:

/usr/lib/pm-utils/sleep.d/10NetworkManager

that's the script that tells NM to wake up.  Not sure exactly when that gets run, but if that definitely sends the message out to the bus, then its either dbus, libdbus, or NetworkManager.  There used to be a bug a long time ago with dbus where it wouldn't send the message if the sender process exited too quickly, which was usually triggered by dbus-send.  Try adding a --print-reply to the call in that script so that it reads:

        dbus-send --system                        \
                --print-reply \
                --dest=org.freedesktop.NetworkManager \
                /org/freedesktop/NetworkManager       \
                org.freedesktop.NetworkManager.wake

so after two weeks I'll call this observer efect!

No resume problems since I added --print-reply

That seems to be a race condition somewhere between that particular script and either dbus not being able to handle that message yet and/or NM not being able to recieve it at that point. 

I would suggest asking some dbus expert on that.

I can confirm this bug. I see it quite often these days (on a wired network).

When I put the following in /etc/dbus-1/system.conf:
<allow receive_interface="*" eavesdrop="true" />

And then run: dbus-monitor --system "interface='org.freedesktop.NetworkManager'"

Sometimes I see the following when I resume:
signal sender=:1.120 -> dest=org.freedesktop.NetworkManager path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=wake

So it is receiving the wake but not the sleep signal.

At other times (when the bug happens), I get this instead:
signal sender=:1.188 -> dest=org.freedesktop.NetworkManager path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=sleep
signal sender=:1.29 -> dest=(null destination) path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChanged
signal sender=:1.29 -> dest=(null destination) path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=StateChange
method call sender=:1.23 -> dest=org.freedesktop.NetworkManager path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=state
signal sender=:1.29 -> dest=(null destination) path=/org/freedesktop/NetworkManager; interface=org.freedesktop.NetworkManager; member=PropertiesChanged

So it gets the sleep signal but never gets the wake signal.

For what it's worth, this makes all my applications using NFS hang, which is not particularly fun.

This is probably a D-Bus bug then.  Michael Meeks discovered a race in D-Bus with short-lived processes that is (as yet) unresolved, which is probably what's causing this issue.

I'd suggest adding --print-reply in the pm-utils script.

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

Sounds reasonable. Richard, do you agree? We can remove the hack once d-bus has been fixed.

Thanks & regards, Phil

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

Just saying "Thanks" for the interim workaround; no 'networking disbled' issues after wakeup on f10 x86_64.

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

The problem with using --print-reply is that the call will block waiting for the reply from dbus. This will cause pm-utils to block in that hook, slowing down the rest of the process as it waits for the hooks to complete. This can take a couple seconds (the last time I checked).

You could mess around with backgrounding the process, but it would really be better if this was fixed in dbus. What pm-utils is doing is perfectly reasonable, and, in fact, the way dbus is supposed to work.

Of course, if the dbus fix is not forthcoming, then workarounds are necessary. I just don't want the workaround to go in and then lose sight of the real problem.

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

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

For as much as you are happy with --print-reply, there is, shall we say, a little issue:

-{*~*}- ~ less /usr/lib/pm-utils/sleep.d/10NetworkManager
/usr/lib/pm-utils/sleep.d/10NetworkManager: No such file or directory

Yep indeed: you 64bits users out there, and I suspect the numbers are increasing, you'd have to edit:

-{*~*}- ~ sudo vim /usr/lib64/pm-utils/sleep.d/55NetworkManager

instead.

male sense though.

Cheers

^^^^^some^admin^please^remove^above^mesage^^^^^

  uname -r
  2.6.27.9-159.fc10.x86_64

GREAT - THE ABOVE HACK KILLED THE 'SUSPEND' ABILITY OF MY LAPTOP, EVEN AFTER REVERTING TO THE FORMER, UNHACKED VERSION OF SAID FILE. 

64BITS PEOPLE, DO _NOT_ EDIT /usr/lib64/pm-utils/sleep.d/55NetworkManager OR DO SO AT YOU OWN RISK.

GENTLEMEN, YOU JUST BROUGHT THE WHOLE 'I DON'T USE LINUX BECAUSE IT DOESN'T WORK' TOPIC ON THE TABLE, RIGHT HERE, RIGHT NOW & MY LANGUAGE SKILLS AREN'T HALFWAY GOOD ENOUGH TO FULLY EXPRESS THE EXACT SUBSTANCE OF MY FEELINGS ABOUT THE SITUATION.

f**CK

Jean-Philippe

^^^^^some^admin^please^remove^above^mesage^^^^^

  uname -r
  2.6.27.9-159.fc10.x86_64

GREAT - THE ABOVE HACK KILLED THE 'SUSPEND' ABILITY OF MY LAPTOP, EVEN AFTER REVERTING TO THE FORMER, UNHACKED VERSION OF SAID FILE. 

64BITS PEOPLE, DO _NOT_ EDIT /usr/lib64/pm-utils/sleep.d/55NetworkManager OR DO SO AT YOU OWN RISK.

GENTLEMEN, YOU JUST BROUGHT THE WHOLE 'I DON'T USE LINUX BECAUSE IT DOESN'T WORK' TOPIC ON THE TABLE, RIGHT HERE, RIGHT NOW & MY LANGUAGE SKILLS AREN'T HALFWAY GOOD ENOUGH TO FULLY EXPRESS THE EXACT SUBSTANCE OF MY FEELINGS ABOUT THE SITUATION.

f**CK

Jean-Philippe

forum thread started to solve the issue (of me being quite innocent in applying suggestions):
http://forums.fedoraforum.org/showthread.php?t=219304

Sorry for the noise. Still angry though.
Jean-Philippe

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

I have had the --print-reply workaround in place for some time now, which was working 100% of the time, but recently it has stopped working so often.

Occasionally now, I send the signal with --print-reply and NetworkManager doesn't re-enable the network.

When this happens, I even tried to send the org.freedesktop.NetworkManager.wake signal several times manually, but I just get the message:
Error org.freedesktop.NetworkManager.AlreadyAsleepOrAwake: Already awake

Next time it happens I will check /var/log/messages.

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

FYI, upstream dbus bug is fdo #896.

https://bugs.freedesktop.org/show_bug.cgi?id=896

What's the state of this at the moment? Can this be closed now, or are we still waiting on a dbus fix?

Just popped up again (it's rare) with:

NetworkManager-0.7.1-8.git20090708.fc11.x86_64
dbus-1.2.12-2.fc11.x86_64

It is not too rare as I am hitting it too with f11.  The dbus bug mentioned in comment #27 has now been resolved.  Can we get a new (patched) version of dbus as the patch was pushed in July but the dbus-1.2.12-2 was built in June?

Nevermind, my bug was related to a typo by someone who created /usr/lib/pm-utils/sleep.d/56dhclient.  Looks like $DEVICE was used to incorrectly read teh vairable $device.  See bug #527641

I've not seen this so far now in Rawhide (dbus-1.2.16-8.fc12.x86_64), anyone else?

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

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 WONTFIX if it remains open with a Fedora 
'version' of '10'.

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 prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

-> F12 since this is still an issue there until/if it gets fixed in dbus...

Upstream claims the dbus bug was fixed; is this reflected in the Fedora build? (I've not seen it so far.)

you're correct, upstream commit is http://cgit.freedesktop.org/dbus/dbus/commit/?id=87ddff6b24d9b9d4bba225c33890db25022d8cbe and F-12 ships with dbus-1.2.16 which has the fix.