Folks,
These days xfce4-session-logout will call UPower over DBUS to request that the system Suspend when the user chooses to do so. upower will then determine whether the user is authorized to perform this amazing feat, and then a simple kernel interface is called to do the heavy lifting.
On a recently installed system running rawhide I notice that this is not working for me. I click "suspend", my network drops...it looks hopeful, then I see the network come back up. Of course, a simple cat into sysfs does suspend the system, so it can work just fine. Ok. So I download the xfce4-session source and start looking. Then I write a simple DBus utility to call upower directly, first to check I am allowed to suspend (which I am), then to call Suspend directly. Same behavior. Something is up in upower but before I go tearing that apart...any debug suggestions?
Meanwhile, I think the solution will be a simple icon on my panel marked "suspend" that writes into sysfs the old fashioned way.
Jon.
On Wed, 2011-11-16 at 05:50 -0500, Jon Masters wrote:
On a recently installed system running rawhide I notice that this is not working for me. I click "suspend", my network drops...it looks hopeful, then I see the network come back up. Of course, a simple cat into sysfs does suspend the system, so it can work just fine. Ok. So I download the xfce4-session source and start looking. Then I write a simple DBus utility to call upower directly, first to check I am allowed to suspend (which I am), then to call Suspend directly. Same behavior. Something is up in upower but before I go tearing that apart...any debug suggestions?
So then I go re-learning how pm-utils works, and the hooks, and in particular /usr/lib64/pm-utils/sleep.d/56atd from the latest at, which has been all systemd-ified but with a broken test on line 14.
Ah well, I guess I was overdue for digging through that anyway. I'll file or hunt down whatever bug is already reported.
Jon.
On Wed, 2011-11-16 at 06:25 -0500, Jon Masters wrote:
Ah well, I guess I was overdue for digging through that anyway. I'll file or hunt down whatever bug is already reported.
On 16 November 2011 11:33, Jon Masters jonathan@jonmasters.org wrote:
atd really shouldn't be restarting on resume anyway....
Richard.
On Wed, 2011-11-16 at 14:21 +0000, Richard Hughes wrote:
On 16 November 2011 11:33, Jon Masters jonathan@jonmasters.org wrote:
atd really shouldn't be restarting on resume anyway....
It's ok, like most things, it's being replaced by the init process so we don't even need to worry...
Jon.
On Wed, 2011-11-16 at 06:25 -0500, Jon Masters wrote:
On Wed, 2011-11-16 at 05:50 -0500, Jon Masters wrote:
On a recently installed system running rawhide I notice that this is not working for me. I click "suspend", my network drops...it looks hopeful, then I see the network come back up. Of course, a simple cat into sysfs does suspend the system, so it can work just fine. Ok. So I download the xfce4-session source and start looking. Then I write a simple DBus utility to call upower directly, first to check I am allowed to suspend (which I am), then to call Suspend directly. Same behavior. Something is up in upower but before I go tearing that apart...any debug suggestions?
So then I go re-learning how pm-utils works, and the hooks, and in particular /usr/lib64/pm-utils/sleep.d/56atd from the latest at, which has been all systemd-ified but with a broken test on line 14.
Ah well, I guess I was overdue for digging through that anyway. I'll file or hunt down whatever bug is already reported.
Thanks for that - I've been seeing the same thing the last couple of days but hadn't had time to dig into it yet.
Adam Williamson wrote:
On Wed, 2011-11-16 at 06:25 -0500, Jon Masters wrote:
On Wed, 2011-11-16 at 05:50 -0500, Jon Masters wrote:
On a recently installed system running rawhide I notice that this is not working for me. I click "suspend", my network drops...it looks hopeful, then I see the network come back up. Of course, a simple cat into sysfs does suspend the system, so it can work just fine. Ok. So I download the xfce4-session source and start looking. Then I write a simple DBus utility to call upower directly, first to check I am allowed to suspend (which I am), then to call Suspend directly. Same behavior. Something is up in upower but before I go tearing that apart...any debug suggestions?
So then I go re-learning how pm-utils works, and the hooks, and in particular /usr/lib64/pm-utils/sleep.d/56atd from the latest at, which has been all systemd-ified but with a broken test on line 14.
Ah well, I guess I was overdue for digging through that anyway. I'll file or hunt down whatever bug is already reported.
Thanks for that - I've been seeing the same thing the last couple of days but hadn't had time to dig into it yet.
I'm not sure if this is the same thing, but on Fedora 16, since about 2 days, whenever I clicked suspend to RAM, the system locked the screensaver, but the system never suspended. This morning, I installed the new test kernel, 3.1.1-2.fc16.x86_64, and now it suspends properly again. Could it have been something in the kernel?
On Wed, 2011-11-16 at 18:25 -0700, Peter Gueckel wrote:
Adam Williamson wrote:
On Wed, 2011-11-16 at 06:25 -0500, Jon Masters wrote:
On Wed, 2011-11-16 at 05:50 -0500, Jon Masters wrote:
On a recently installed system running rawhide I notice that this is not working for me. I click "suspend", my network drops...it looks hopeful, then I see the network come back up. Of course, a simple cat into sysfs does suspend the system, so it can work just fine. Ok. So I download the xfce4-session source and start looking. Then I write a simple DBus utility to call upower directly, first to check I am allowed to suspend (which I am), then to call Suspend directly. Same behavior. Something is up in upower but before I go tearing that apart...any debug suggestions?
So then I go re-learning how pm-utils works, and the hooks, and in particular /usr/lib64/pm-utils/sleep.d/56atd from the latest at, which has been all systemd-ified but with a broken test on line 14.
Ah well, I guess I was overdue for digging through that anyway. I'll file or hunt down whatever bug is already reported.
Thanks for that - I've been seeing the same thing the last couple of days but hadn't had time to dig into it yet.
I'm not sure if this is the same thing, but on Fedora 16, since about 2 days, whenever I clicked suspend to RAM, the system locked the screensaver, but the system never suspended. This morning, I installed the new test kernel, 3.1.1-2.fc16.x86_64, and now it suspends properly again. Could it have been something in the kernel?
No, that sounds like exactly the bug discussed above, and I would bet dollars to donuts you got an update to 'at' at the same time as you got an update to the kernel. The 'at' update fixes the bug.
Adam Williamson wrote:
No, that sounds like exactly the bug discussed above, and I would bet dollars to donuts you got an update to 'at' at the same time as you got an update to the kernel. The 'at' update fixes the bug.
Yes, that is correct. Along with the kernal was at-3.1.13-5.fc16.
Thanks for the info :-)
-
Adam Williamson -
Jon Masters -
Peter G. -
Richard Hughes