fast-user-switch heavy cpu usage

I find the same, especially as I have a large /etc/passwd from an NIS domain. It makes the system practically unusable taking > 10 minutes just to log on unless you kill the applet.

I can confirm this. getent passwd | wc-l gives me 9000 users here. fast-user-switch-applet is running for more then 10 minutes now and hogs the cpu.

The real problem is that when a new user without existing .g* files in his home directory logs in, gnome loads the fast-user-switch-applet (which doesn't make much sense with so many users as pam allows only users in a special group to log in to this particular machine here). Gnome startup (e.g. panel loading) does not continue until fast-user-switch-applet is initialized, which takes ages. The user can't work for half an hour...

Is there a possibility to disable fast-user-switch-applet for all users? Uninstalling is not an option as ubuntu-desktop depends on it.

Same behavior observed on another system with large NIS passwd file.

$ apt-cache policy fast-user-switch-applet
fast-user-switch-applet:
  Installed: 2.22.0-0ubuntu2
  Candidate: 2.22.0-0ubuntu2
  Version table:
 *** 2.22.0-0ubuntu2 0
        500 http://ubuntu.media.mit.edu hardy/main Packages
        100 /var/lib/dpkg/status

It seems to be doing a lot of gtk work, probably to display users to switch to, e.g.
$ ltrace -o /tmp/trace -p $(pidof fast-user-switch-applet)
^C
$ awk '{print $2}' /tmp/trace | sed 's/(.*$//' | perl -lne '$F{$_}++; END { foreach (keys %F) { print "$_ $F{$_}"; } }' | sort -n -k 2 | tail
_instance_is_a 35
g_cclosure_marshal_VOID__OBJECT 40
g_signal_connect_data 45
<... 63
gtk_menu_attach 31686
gtk_menu_get_type 31686
gtk_menu_reorder_child 31687
g_type_check_instance_cast 123389
g_utf8_collate 182765

I'm in an NIS environment with over 8000 users, and am seeing exactly the same problem. Because this manifests as a blank desktop with no panels, it really is not only crippling to users, but nearly impossible for the uninitiated to diagnose.

The large amount of CPU usage is secondary, really, the first thing that needs to be fixed is the fact that this blocks the user's desktop initialization. Does it need to?

I want to chime in to say in my NIS environment the same behavior manifests. Other behavior is the desktop is unresponsive to user input and the top&bottom taskbars are crunched and unresponsive to user input. I have no idea whether fast-user-switch ever finishes initializing (as others have suggested it does) because when I discovered this behavior the system had been logged in for several days and the fast-user-switch process had consumed 7000+ minutes of CPU time and was still taking 100% CPU.

root@libre:~# getent passwd | wc -l
46929

FWIW I have a workaround to suggest

root@libre:~# chmod -x /etc/init.d/autofs /etc/init.d/nis

After doing this and a reboot the user login works fine, and comes right up, and the system is very responsive.

Your chmod workaround has simply disabled NIS and automounting, removing all network user and filesystem access from your system. That will certainly solve the problem, but for most people who have this problem, that's throwing out the baby with the bath-water. There are also more standard ways to turn off services.

After having lived with this for a while, I think the core problem is not the user list itself, but the fact that the user-switcher wants to look at everyone's home directory. If there are 10,000 users (not as uncommon as you'd think), this means 10,000 network directory lookups (possibly more if it's looking at subdirs as well, I'm not 100% certain what it's fetching other than a potential icon to use for the login session). I discovered this when I went to my automounted /home directory and found all of the users pre-mounted, which should only happen if I'm actually reading their directories.

Perhaps the right thing to do here is to simply add in some delays. It doesn't have to search all of the user homedirs at once, does it? Would pausing for 500ms between lookups hurt anything? What's more, is it even useful to be looking up fast-user-switch info when there are thousands of users?

I am only one person and have only a few large-deployed (~200 users)
sites to administrate, but I have to wonder if it is worth it to even
*have* fast-user-switching in large-scale environments... I have always
turned fast-user-switch-applet off and disabled everything I can in
GConf to have this not be an issue (and to not clutter up the top panel)
- again, what was the reason for even *having* this feature enabled on a
panel by default?

It is sensible to have the applet on the panel by default as one of Ubuntu's goal is to provide a very good out-of-the-box experience for the average user. Those admins who deploy a large site can disable it with gconf as it doesn't make sense in this case.

Anyway this is a bug that MUST be fixed.

In my opinion it would be a good idea if the applet would automatically remove itself if there is only one local user or if there are very much users (perhaps more than 100), but this is another topic that should not be discussed here.

how to disable it via gconf for all users (even new/lateron created ones)?

It would be good if the dependency to ubuntu-desktop could be removed.

I am an administrator in the same position that everyone above me is in. We get reports from our large user base about not being able to even use a desktop for upwards of 10 minutes, panels not displaying etc. If anyone knows the way to disable this be default I'd appreciate it much. If I can find out some kind of workaround I promise to post it.

For those interested in a work around I was able to get fantastic results with the following:

gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory --type list --list-type string --set /apps/panel/global/disabled_applets ['OAFIID:GNOME_FastUserSwitchApplet']

If you've got any custom packages you deploy in your infrastructure you'll be able to put it in a .postinst like I am

This work around was tested on a Hardy Heron 8.04.1 machine with home directories mounting through NFS.

Hello,

I've prepared a patch that I believe fixes this issue. Unfortunately I don't have a system with large numbers of users to test it on. The patched package is available in my PPA for Intrepid. Could someone please test?

    http://launchpad.net/~ted-gould/+archive

Thank you.

Version: fast-user-switch-applet_2.24.0-0ubuntu7~ppa5

Ted, I'll be in a position to test this tomorrow. I'll comment again with my results. Thanks for taking the first step to write a patch!

Ted, your patched version works great for me (~10.000 users). I found no
problems.

On Thu, 2008-11-06 at 13:28 +0000, Martin wrote:
> Ted, your patched version works great for me (~10.000 users). I found no
> problems.

Great! I'm glad that it works. Now, to play the SRU game :)

ACK for SRU.

This bug was fixed in the package fast-user-switch-applet - 2.24.0-0ubuntu7

---------------
fast-user-switch-applet (2.24.0-0ubuntu7) jaunty; urgency=low

  * Added debian/patches/73_max_users_from_passwd.patch which makes it so
    there is a maximum of 15 users that can be read from the password file
    before going into overload mode. In that mode there are no users shown
    from the password files, only logged in users and an other that will
    take you back to GDM. Fixes LP: #203217
  * Added debian/patches/94_user_manager_signals.patch which adds removal
    of signals on shutdown. Each of these signals are invalid if they're
    called anywhere after this function.
  * Updated 90_status_management.patch to better handle removal of signals
    which should fix LP: #285797
  * Updated 84_session_management.patch to properly disconnect the signals
    related to the DBus events it is watching.
  * 90_status_management.patch: Changing 'Online' to 'Available' fixing
    LP: #279057
  * 90_status_management.patch: More work into handling the pixels around
    the applet. This will be the final version for how those pixels are
    handled, closing LP: #272824

 -- Ted Gould <email address hidden> Thu, 06 Nov 2008 12:48:15 -0600

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I tried the fix proposed in Ted's PPA for Hardy, but it doesn't work yet.
It continues to use 100% of the CPU, but this time, gnome startup ends well so the user can work.
However, on use or logout, the applet crashes.
getent passwd | wc -l gives me more than 3500 users

apt-cache policy fast-user-switch-applet
fast-user-switch-applet:
  Installé : 2.22.0+svn20080815-0ubuntu3~ppa1~hardy1
  Candidat : 2.22.0+svn20080815-0ubuntu3~ppa1~hardy1

Can we please have this fixed for Hardy, causing massive problems.

This update has been in intrepid-proposed for over three months, without any testing feedback. Can anyone please test this version and tell us whether it still works normally, and this bug is fixed for you? Thanks!

No problems here at all with 2.24.0-0ubuntu7

I still have problem with 2.24.0-0ubuntu6.1, from intrepid-proposed.

Same as above (https://bugs.launchpad.net/ubuntu/intrepid/+source/fast-user-switch-applet/+bug/203217/comments/23) : it uses 100% of the CPU and the applet is freezed.

Since comment 26 talks about Jaunty, and comment 27 said that the update didn't fix this, I mark this as verification-failed.

So is anything being done here? I can see two possible (easy) solutions:

1) Simply use gksudo in the .desktop file to necessitate root privs to run it
2) (probably better) Integrate policykit into it for those functions, since by default, normal users can't kill/re-nice other users' procs

Am I missing anything?

Ahh, crap! Sorry, wrong bug. /me needs to read more

For Ubuntu 8.10 (Intrepid), I enabled the "proposed" repository and updated fast-user-switch-applet from 2.24.0-0ubuntu6 to 2.24.0-0ubuntu6.1. It is no longer chewing up 98% of the cpu. Thanks.

Current SRU was removed from proposed for bug 279057. If this is still an issue, it needs to be reuploaded without string changes.

I'm still getting high CPU usage after a few hours of usage.

The system is using LDAP with just 5 users right now as It is a developmnet environment. In production there will be hundreds of users.

strace shows an infinite print:

strace -p `pidof fast-user-switch-applet`

##########################
...
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
poll([{fd=25, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=25, revents=POLLIN|POLLERR|POLLHUP}])
...
##########################

Using lsof, the file descriptor 25 is:

##########################
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
...
fast-user 3552 usuario 25u sock 0,4 13075 can't identify protocol
...
##########################

f-u-s-a version is:

fast-user-switch-applet 2.24.0-0ubuntu13

In Jaunty I get this:

strace -p `pidof fast-user-switch-applet`
#############################
...
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLIN|POLLHUP}])
...
##############################

lsof|grep fast-us|grep 3u
fast-user 3580 rune 3u sock 0,4 12944 can't identify protocol
...

Version:
fast-user-switch-applet 2.24.0-0ubuntu13

Oh I forgot.
I am also in an ldap environment, if that makes a difference.

If I kill the process and reload it, it doesn't use 100% cpu.

This is still happening to me in Jaunty, just as in my comment #34. I reopened the bug as I think it's not really fixed. I'll take a look at the max_users patch and see if I can help.

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the
report. The bug has been fixed in newer releases of Ubuntu.

Thank you for taking the time to report this bug. This issue has been fixed in newer versions of Ubuntu, and Jaunty is EOL, so I am closing this bug task.