I have been seeing CPU usage (dual Opteron) averaging about 50% on both CPU's. Iotop showed gconfd-2 writing at 40K/s. An emerge -C vino, and killing the vino process brought things back to normal Reproducible: Always My emerge --info Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.3, glibc-2.10.1-r0, 2.6.30-gentoo-r2 x86_64) ================================================================= System uname: Linux-2.6.30-gentoo-r2-x86_64-AMD_Opteron-tm-_Processor_242-with-gentoo-2.0.1 Timestamp of tree: Tue, 14 Jul 2009 20:00:01 +0000 app-shells/bash: 4.0_p24 dev-java/java-config: 1.3.7-r1, 2.1.8-r1 dev-lang/python: 2.5.4-r2, 2.6.2-r1 dev-util/cmake: 2.6.4 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.0 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=opteron -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=opteron -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sfperms strict unmerge-orphans" GENTOO_MIRRORS="http://gentoo.osuosl.org http://ftp.ucsb.edu/pub/mirrors/linux/gentoo http://cudlug.cudenver.edu/gentoo http://gentoo.binarycompass.org" LANG="en_us" LC_ALL="C" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/devnull" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl administrator aiglx alsa amd64 apache2 auctex audiofile bash-completion bcmath berkdb blas bonobo bzip2 cairo calendar cdrom clamav clamd cli clisp colordiff consolekit cracklib crypt ctype cups dbus debugger deprecated dga discouraged divx-linux dri dvd dvdr dvdread emacs emul-linux86 esd fam fastcgi fbcon ffmpeg flac fortran ftp gd gdbm glut gmail gnome gnome-keyring gphoto2 gpm gstreamer gtk hal iconv imagemagick ipv6 isdnlog java javascript jpeg kerberos kpathsea latex latin1 leim lesstif libclamav libnotify libwww logrotate mad maildir mbox mcal midi mime mmx mmxext mng mouse mozcalendar mozilla mpeg2 mpi mudflap multilib mysql mysqli nat ncurses nls nocd nosendmail nptl nptlonly nsplugin nvidia objc offensive ogg opengl openmp osc oscar pam pcre pdf perl png policykit pop pop3d portaudio posix ppds pppd preview-latex python query-browser readline reflection regex replytolist rtc samba sasl session sharedmem sockets sound source sox speex spl sse sse2 ssl svg symlink sysfs tcltk tcpd tetex thunderbird truetype unicode usb vhosts vorbis wxwindows xcomposite xine xmail xorg xulrunner xvid" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I just did a reboot, vino is running, and is behaving itself.
Well the hog was back. Emerge -C of vino and killing vino job fixed it. Unlike before when Re-emerging vino and rebooting the hog was back. I don't see a need for vino on my system, but there is something fishy with it, or with something it uses.
It seems vino got reinstalled again, and after a reboot is causing no problem. I don't seem to have anything useful that might help in tracking this down. I might note that at present /usr/libexec/vino-server is sleeping. When it was hogging the CPU there were two vino things listed by ps, but I don't recall the name of the other one.
Well, vino is at it again. When it running ps shows two copies, such as 3110 m /usr/libexec/vino-server -- S 3329 m /usr/libexec/vino-server R On every query with ps the process ID of the one with "R" changes. If the one with "S" is killed the process ID of both changes. If the one with "R" is killed only its ID changes as it does whether it is killed or not. The only way to stop it from hogging the CPU is an "emerge -C vino", and then kill the vino jobs. Perhaps all this will suggest something?
Maybe it could be this problem: http://bugzilla.gnome.org/show_bug.cgi?id=167610 what do you get for 'xdpyinfo | grep DAMAGE'?
(In reply to comment #5) > Maybe it could be this problem: > http://bugzilla.gnome.org/show_bug.cgi?id=167610 Not exactly the same as I have nvidia drivers. > what do you get for 'xdpyinfo | grep DAMAGE'? I get "DAMAGE"
do you use session-saving ? If so I think this is a new bug and should be reported upstream. You'll have to provide vino version, gnome-session version, and a backtrace or a profile to see where vino is looping like crazy.
Maybe this hog is caused by vino-server being started lots of times, then, it would be: http://bugzilla.gnome.org/show_bug.cgi?id=579355 (I say this because of comment #4 that says that two processes seems to be being executed)
I think comment 8 has the answer. In the gconf editor, I have auto_save_session checked. For the record, vino and gnome-session are both at version 2.26.2.
In 2.26.2-r1 with locale installation fix. Thanks for reporting.
I just rebooted with vino-2.26.2-r1. ps shows 687 m /usr/libexec/vino-server -- R 3348 m /usr/libexec/vino-server -- S and the CPU is busy. After a "killall vino-server", I have 3646 m /usr/libexec/vino-server -- S and the CPU is taking it easy.
Sorry. I just rebooted again, and all seems normal. Maybe it is o.k.
