ubuntu-sso-login responsible for an unreasonable number of CPU wakeups, despite having nothing to do

[Steve Langasek]

Binary package hint: ubuntu-sso-client

If I'm reading powertop output right, ubuntu-sso-client in maverick is responsible for a consistent 10 wakeups per second on my laptop. This, despite the fact that I am not using Ubuntu One on this laptop, so there is no discernable reason why this process should be running *at all*.

Won't someone think of the polar kittens and their melting ice sheets? Please fix this service to poll more sensibly or, if that's not possible (the event loop appears to be handled by twisted, so maybe this isn't under your direct control), fix it to not start up on systems that aren't using Ubuntu One.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: ubuntu-sso-client 1.0.3-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
Date: Mon Oct 11 21:11:12 2010
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: ubuntu-sso-client

[Natalia Bidart (nataliabidart)]

Hello Steve!

Thanks for your report. On one hand, we have submitted an update to the package so the DBus service runs the gtk mainloop instead of twisted's. On the other hand, the DBus service is started by activation, so if you have it running, that means that some service started it. Current clients of the service are Ubuntu One and Software Center.

Cheers!

[Steve Langasek (vorlon)]

On Tue, Oct 12, 2010 at 02:03:43PM -0000, Naty Bidart wrote:

> Thanks for your report. On one hand, we have submitted an update to the
> package so the DBus service runs the gtk mainloop instead of twisted's.
> On the other hand, the DBus service is started by activation, so if you
> have it running, that means that some service started it. Current
> clients of the service are Ubuntu One and Software Center.

Ok, I think I had opened software center once or twice since the last login,
probably when testing out apt.ubuntu.com. But shouldn't the SSO service
eventually shut itself down when idle, instead of polling indefinitely?

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Natalia Bidart (nataliabidart)]

HI Steve, thanks for your answer.

Can you please detail how can I measure/see this polling you're referring to? The service will not shutdown by itself, but is not doing any explicit polling either.

Thanks!

[Steve Langasek (vorlon)]

On Wed, Oct 13, 2010 at 12:43:31PM -0000, Naty Bidart wrote:
> HI Steve, thanks for your answer.

> Can you please detail how can I measure/see this polling you're
> referring to? The service will not shutdown by itself, but is not doing
> any explicit polling either.

If you run 'sudo powertop' in a terminal, this will show the top causes of
system wakeups. On a system that has ubuntu-sso-login running, it shows up
for me with a steady 10.0 wakeups per second. You may want to make your
terminal taller if you have a busy system with lots of other causes of
wakeups; but you'll probably notice that all of the higher causes for
wakeups are either the kernel / hardware, or applications that you're
actively using, not background services that should be idle.

The most likely causes for wakeups (at the C/syscall level) would be some
sort of sleep/usleep call, or a select() with an unreasonably short timeout.
Mapping this to python code is somewhat trickier; as a general rule, it's
important for any application to consolidate as many of its timers as
possible into a single timer, so that it can, say, wake up once a second, do
its work, and put the CPU back to sleep.

I was looking for a good reference to power-efficient desktop programming
since I know such things have been written, especially for GNOME; but I'm
coming up empty at the moment. However, I did find
<https://bugzilla.redhat.com/show_bug.cgi?id=239893>, which describes a
similar "10/sec" wakeup problem with another PyGTK app, so maybe that will
provide some clues here?

BTW, what's the reason for the service not shutting itself down after an
idle timeout? I thought this was fairly standard practice for dbus
services.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Natalia Bidart (nataliabidart)]

Hello Steve,

Again, thanks a lot for your time and detail on this report.

I've just tested ubuntu-sso-login version 1.0.3-0ubuntu1 and 1.0.4-0ubuntu1 (you can get the later enabling the maverick-proposed repository, for instructions you can read https://wiki.ubuntu.com/Testing/EnableProposed) and I can confirm that in the former the service presents a 10/s wakeup rate and with the latter the wakeups are 0/s when not being used.

Can you please confirm this yourself?

On the other hand, answering the question about why the service doesn't shutdown itself: currently we have no way of deciding if the service is being used or not. This service opens a GTK UI for the user to login or register, and that window can remain opened as long as the user wants, so the backend layer can't decide when no one is accessing the service.

Regards, Natalia.

[Steve Langasek (vorlon)]

Hi Naty,

Yes, I'm happy to confirm that after upgrade to maverick-updates, ubuntu-sso-login is no longer causing spurious wakeups on my laptop. Thanks for the fix!

[Natalia Bidart (nataliabidart)]

Thank you for the help on debugging!