when having lots of incoming ssh connections, one will notice, that the memory allocated to console-kit-daemon is constantly growing. I recently had some severe server issues (services were not able to run anymore due to no more memory available) due to this. As a first step I added a cron job to restart consolekit once a week, but that's quite ugly. This bug is hanging around for quite a long time ! Reproducible: Always Steps to Reproduce: 1.do ssh to your machine ofen 2.watch memory usage of console-kit-daemon grow indefinitely 3. Expected Results: memory usage should be "nearly" constant. Portage 2.1.9.25 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.36-gentoo-r5 i686) ================================================================= System uname: Linux-2.6.36-gentoo-r5-i686-Intel-R-_Core-TM-2_Duo_CPU_P8800_@_2.66GHz-with-gentoo-1.12.14 Timestamp of tree: Wed, 02 Feb 2011 12:50:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r1 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=prescott -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" 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="/var/lib/layman/science /usr/local/portage" SYNC="rsync://brklev2a.fact.brk.eu.mars/gentoo-portage" USE="X a52 aac acl alsa apache2 berkdb bzip2 cairo cli consolekit cracklib crypt cups cxx dbus dri dts dv dvb dvd exif extras ffmpeg firefox fortran gd gdbm gimp gnome gnutls gpm gstreamer gtk hal hddtemp iconv ieee1394 ipv6 jpeg libnotify lm_sensors modules mudflap mysql ncurses nls nntp nptl nptlonly nsplugin objc opengl openmp pam pcre perl png policykit postgres pppd python quicktime readline session sqlite3 ssl sysfs tcl tcpd thunar tiff unicode x264 x86 xcomposite xml xorg xvmc zlib" ALSA_CARDS="hda-intel" 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_ftp proxy_http rewrite setenvif so speling status suexec unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="X usblcd lcd2usb" LINGUAS="en" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel fbdev vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
You have to provide more information than that. For example, meaningful valgrind output. Saying something "doesn't work" or "it's leaking" doesn't really cut it.
(In reply to comment #1) > You have to provide more information than that. For example, meaningful > valgrind output. Saying something "doesn't work" or "it's leaking" doesn't > really cut it. > No, I do *NOT* have to do that. Besides valgrind is beyond my knowledge. Btw. "memory leakage" (http://en.wikipedia.org/wiki/Memory_leak) is a commonly known phrase and far from "it does not work". It says that the amount of memory a program uses will constantly grow (because of a programming bug) and tracing that requires more knowledge that I (and probably a lot of other gentoo users) do have. So requesting detailed programming/debugging knowledge from a person entering a bug report is out of place to me. Sorry.
You're making the assumption others can reproduce this leak. ConsoleKit has been running here since it was added to tree, and I'm not seeing this.
(In reply to comment #3) > You're making the assumption others can reproduce this leak. > ConsoleKit has been running here since it was added to tree, and I'm not seeing > this. > So what Google spits out for you, is really true. Your ability to neglect bugs and your warm and friendly cooperation was no underestimation. Also your ability to solve bugs simply by closing then is also impressive. Please, is there someone less arrogant reading these bugs, who can direct me how to trace this down instead of telling me I'm just imagining this bug and I'm stupid. For those who are really willing to help: I do ssh ~ twice every 15 secs (7*24) to this machine and run out of mem (3G) after ~ 2 month. Short instructions on how to use valgrind to track this down are highly appreciated, especially how to limit the output size, since I'd probably would have to log over a longer time span.
(In reply to comment #4) ... > So what Google spits out for you, is really true. Your ability to neglect bugs > and your warm and friendly cooperation was no underestimation. Also your > ability to solve bugs simply by closing then is also impressive. > Please, is there someone less arrogant reading these bugs, who can direct me > how to trace this down instead of telling me I'm just imagining this bug and > I'm stupid. I don't know what link(s) you found on Google that led you to believe we don't care about users and or bug reports. As a member of User Relations and a council member, can you please point me to what gave you that impression? Samuli cares about this bug, he just isn't able to reproduce it. In order to work on this bug report, we must first be able to reproduce it so that we can determine the source. As he couldn't reproduce it, he asked you for that information. I apologize for not commenting on this bug sooner, but I went to FOSDEM last weekend and this week I'm out of home, with limited resources and catching up. > For those who are really willing to help: I do ssh ~ twice every 15 secs (7*24) > to this machine and run out of mem (3G) after ~ 2 month. Short instructions on > how to use valgrind to track this down are highly appreciated, especially how > to limit the output size, since I'd probably would have to log over a longer > time span. If it takes around 2 months to run out of memory (3GB) when you establish approximately 11520 connections per day and 691200 in 2 months, if the memory leak is on console-kit-daemon, it must be a *very* small memory leak - which probably will make it harder to find. I don't think we have a guide to use valgrind to find memory leaks on Gentoo, so here are 2 links for valgrind documentation: http://valgrind.org/docs/ http://valgrind.org/docs/manual/QuickStart.html We do have a guide for meaningful backtraces on Gentoo: http://www.gentoo.org/proj/en/qa/backtraces.xml Searching on google for "using valgrind to detect memory leak" returned a few useful links, including the following: http://www.cprogramming.com/debugging/valgrind.html http://valgrind.org/gallery/linux_mag.html If you can provide information on how to duplicate the bug or the traces that identify the memory leak, that'd be great and allow this bug report to be worked on. If you can't, we'll have to wait for anyone else that hits your issue to report here and hope he/she can provide that information. If you ever find that your bug report hasn't been treated "appropriately" or that a developer isn't being respectful, please step back, take some time off and later revisit the bug report. If you still feel the same, please contact the User Relations team and we'll try to assist you. http://www.gentoo.org/proj/en/userrel/
