Hello All,
I'm seeing a strange issue when I suspend my system. If I suspend using either the command:
"dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend"
or running "pm-suspend" as root, the system will shutdown and go into suspend mode like it should.
But if I execute either of these commands again, it doesn't suspend. What I found is that after suspending the first time I can see that "/usr/sbin/pm-suspend" is still active. After killing this process I am then able to suspend again.
Any ideas on what's going on here? Why would the suspend process still be running after resuming from suspend?
Thanks,
Randy
Am 30.06.2012 06:28, schrieb Randy:
Hello All,
I'm seeing a strange issue when I suspend my system. If I suspend using either the command:
"dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend"
or running "pm-suspend" as root, the system will shutdown and go into suspend mode like it should.
But if I execute either of these commands again, it doesn't suspend. What I found is that after suspending the first time I can see that "/usr/sbin/pm-suspend" is still active. After killing this process I am then able to suspend again.
Any ideas on what's going on here? Why would the suspend process still be running after resuming from suspend?
Thanks,
Randy
hi,
do you have any custom hooks in /etc/pm/sleep.d/ ? I had a similiar problem once when I created a custom hook and didn't fork the process I was starting inside the hook, so pm-suspend would wait forever for the hook to exit. /var/log/pm-suspend.log should be able to show you at what hook it is hanging.
On 06/30/2012 06:16 AM, Marius T. wrote:
Am 30.06.2012 06:28, schrieb Randy:
Hello All,
I'm seeing a strange issue when I suspend my system. If I suspend using either the command:
"dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend"
or running "pm-suspend" as root, the system will shutdown and go into suspend mode like it should.
But if I execute either of these commands again, it doesn't suspend. What I found is that after suspending the first time I can see that "/usr/sbin/pm-suspend" is still active. After killing this process I am then able to suspend again.
Any ideas on what's going on here? Why would the suspend process still be running after resuming from suspend?
Thanks,
Randy
hi,
do you have any custom hooks in /etc/pm/sleep.d/ ? I had a similiar problem once when I created a custom hook and didn't fork the process I was starting inside the hook, so pm-suspend would wait forever for the hook to exit. /var/log/pm-suspend.log should be able to show you at what hook it is hanging.
The only thing that I have in sleep.d is 90alsa, but I didn't place this file there. It must have been done when a package was installed. If I rm this file, then it works ok.
Do you think that it's ok to not have this file there? I'll have to check if removing it prevents my sound from working after a resume.
Am 30.06.2012 16:01, schrieb Randy:
The only thing that I have in sleep.d is 90alsa, but I didn't place this file there. It must have been done when a package was installed. If I rm this file, then it works ok.
Do you think that it's ok to not have this file there? I'll have to check if removing it prevents my sound from working after a resume.
this file is part of alsa-utils and as far as I understand this was added as a workaround for some buggy application behaviour: https://bugs.archlinux.org/task/17239
I'm not sure what the hook actually does, but it doesn't seem to be neccessary - at least on my systems (I use systemd to suspend, so these hooks are not even run on my systems).
Anyway, if this hook indeed causes the problem I think you should file a bug report. Maybe whatever this hook fixes has been fixed upstream and it isn't even needed anymore...
On 06/30/2012 11:11 AM, Marius T. wrote:
Am 30.06.2012 16:01, schrieb Randy:
The only thing that I have in sleep.d is 90alsa, but I didn't place this file there. It must have been done when a package was installed. If I rm this file, then it works ok.
Do you think that it's ok to not have this file there? I'll have to check if removing it prevents my sound from working after a resume.
this file is part of alsa-utils and as far as I understand this was added as a workaround for some buggy application behaviour: https://bugs.archlinux.org/task/17239
I'm not sure what the hook actually does, but it doesn't seem to be neccessary - at least on my systems (I use systemd to suspend, so these hooks are not even run on my systems).
Anyway, if this hook indeed causes the problem I think you should file a bug report. Maybe whatever this hook fixes has been fixed upstream and it isn't even needed anymore...
Ok. Thanks for the help!
On 06/30/2012 06:28 AM, Randy wrote:
Hello All,
I'm seeing a strange issue when I suspend my system. If I suspend using either the command:
"dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend"
or running "pm-suspend" as root, the system will shutdown and go into suspend mode like it should.
But if I execute either of these commands again, it doesn't suspend. What I found is that after suspending the first time I can see that "/usr/sbin/pm-suspend" is still active. After killing this process I am then able to suspend again.
Any ideas on what's going on here? Why would the suspend process still be running after resuming from suspend?
Thanks,
Randy .
I have the same issue. Did post about it while back. I started disabling modules at boot-up and found that if I remove "bluetooth" my issue goes away. Assuming something does not unload cleanly at the first suspend.
Manne
arch-general@lists.archlinux.org