Stefano Zacchiroli wrote:
I'm experiencing the same behaviour, but I haven't yet managed to discover the parameters which make the behaviour deterministically reproducible.
Having gtkpbbuttons running seemed to be a parameter for me, but were not always true.
BTW the most annoying fact about this pbbuttonsd is that when pbbuttonsd crashes there's no way to get it up and running again without rebooting the machine. "/etc/init.d/pbbuttonsd stop" doesn't work and after manually -9-killing pbbuttonsd there's no way to start it again since it complaints that another daemong is running even it that's not the case, are there any hiddent pid/lock files I'm not aware of?
Exactly the same happens to me. Defunct processes that tried to suspend the computer are viewable with ps -A, but have never been able to kill them: I had to reboot.
Another detail, which may be helpful, is that sometimes while shutting down the machine after the pbbuttonsd crash while trying to put the machine to sleep, the laptop enter the sleep just before the kernel "power down" message. Then when I wake up the laptop the shutdown procedure completes actually switching off the machine.
Again, that also happened to me, but only when rebooting due to a crash. I mean, when halting or rebooting the computer with no bad behaviour from pbbuttonsd, then everything works fine always.
Anyway, I am now running pbbuttonsd 0.6.2-1, and the strange behaviours seem to have disappeared. Still checking, though.
-- Jaume Sabater http://linuxsilo.net "Ubi sapientas ibi libertas"