console-kit-daemon shenanigans
so for a long time i was wondering what console-kit-daemon was and why were there so many of them running on my machine.
example:
ono-sendai ~ % ps -eLf | grep console-kit | grep -v grep
root 1981 1 1981 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1983 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1985 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1986 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1987 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1988 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1989 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1991 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1992 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1993 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1994 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1995 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1996 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1997 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1998 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 1999 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2000 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2001 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2002 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2003 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2004 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2005 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2006 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2007 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2008 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2009 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2010 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2011 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2012 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2013 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2014 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2015 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2016 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2017 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2018 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2019 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2020 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2021 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2022 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2023 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2024 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2025 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2026 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2027 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2028 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2029 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2030 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2031 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2032 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2033 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2034 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2035 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2036 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2037 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2038 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2039 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2040 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2041 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2042 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2043 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2044 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2045 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2047 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2049 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1981 1 2105 0 65 Oct15 ? 00:00:00 /usr/sbin/console-kit-daemon
ono-sendai ~ % ps -eLf | grep console-kit | grep -v grep | wc -l
6565.
65 running daemons, which granted, are not taking up a dumb amount of memory but are annoying since in a “ps -eLf” or htop tree view take up many lines.
here is what freedesktop.org had to say about ConsoleKit:
ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them.
definition of Session, Session Leader, & Seat as per freedesktop.org:
Session
A session is a collection of all processes that share knowledge of a secret. In the typical (or ideal) case, these processes all originate from a single common ancestor.
As an implementation detail, for now, this secret should be stored in the process environment by the session leader under the name XDG_SESSION_COOKIE. When and if we are able to take advantage of a mechanism in the underlying system to store session registration information - we will. However, such a mechanism is not known at the present time.
Using an environment variable does have certain advantages. For one, it is quite easy for a process to opt-out of a Session by simply unsetting the XDG_SESSION_COOKIE variable.
Limitations of using an environment variable implementation include not being able to strictly limit visibility of the secret to a particular process ancestry. So, it is not possible to enforce session boundaries other than on a per-user basis. For example, we don't yet have a way to prevent a process from moving between sessions owned by the same user.
Session leader
The session leader is the process that requests that a new session be opened. It does this by connecting to the D-Bus system bus and using either org.freedesktop.ConsoleKit.Manager.OpenSession() or org.freedesktop.ConsoleKit.Manager.OpenSessionWithParameters(). The session that it registers will remain open until the connection to the system bus is lost or it calls org.freedesktop.ConsoleKit.Manager.CloseSession().
The session leader is the only process for which CloseSession() will be allowed.
Seat
A seat is a collection of sessions and a set of hardware (usually at least a keyboard and mouse). Only one session may be active on a seat at a time.
At the present time, all Sessions that are considered "local" to a system will be added the the first Seat and every other Session will be added to its own Seat.
True, hardware, multi-seat capabilities will be added in a later release.
So what i am gathering from this is that on my personal laptop that will have at most 3 actual people logged in at any given moment the usage fo 65 console-kit-daemon’s is a bit excessive. lets fix that.
after some digging around and much googling, i found two values which were originally housed in /usr/src/KERNEL VERSION/include/linux/tty.h and have now been moved to /usr/src/KERNEL VERSION/include/linux/vt.h
which are :
MAX_NR_CONSOLES & MAX_NR_USER_CONSOLES
these two defines explained here:
* Console (vt and kd) routines, as defined by USL SVR4 manual, and by
* experimentation and study of X386 SYSV handling.
*
* One point of difference: SYSV vt's are /dev/vtX, which X >= 0, and
* /dev/console is a separate ttyp. Under Linux, /dev/tty0 is /dev/console,
* and the vc start at /dev/ttyX, X >= 1. We maintain that here, so we will
* always treat our set of vt as numbered 1..MAX_NR_CONSOLES (corresponding to
* ttys 0..MAX_NR_CONSOLES-1). Explicitly naming VT 0 is illegal, but using
* /dev/tty0 (fg_console) as a target is legal, since an implicit aliasing
* to the current console is done by the main ioctl code.so if i am reading this correctly, then this means that this is for numbering vt’s and vc’s. so why have so many of them. lets change these values, recompile our kernel and test.
values changed :
#define MAX_NR_CONSOLES 63 /* serial lines start at 64 */
#define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */
to:
#define MAX_NR_CONSOLES 15 /* serial lines start at 64 */
#define MAX_NR_USER_CONSOLES 15 /* must be root to allocate above this */
results:
cbodden@ono-sendai ~ % ps -eLf | grep console-kit | grep -v grep
root 1877 1 1877 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1879 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1881 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1882 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1883 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1884 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1885 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1887 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1888 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1889 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1890 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1891 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1892 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1893 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1894 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1943 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1948 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
root 1877 1 1999 0 18 14:50 ? 00:00:00 /usr/sbin/console-kit-daemon
cbodden@ono-sendai ~ % ps -eLf | grep console-kit | grep -v grep | wc -l
1818.
that is a bit better.
this was tested using kernel version 3.6.2 (gentoo-sources):
ono-sendai ~ % uname -a
Linux ono-sendai 3.6.2-gentoo-poa #1 SMP PREEMPT Thu Oct 18 14:47:38 EDT 2012 x86_64 Intel(R) Core(TM)2 Duo CPU L9600 @ 2.13GHz GenuineIntel GNU/Linux
ono-sendai ~ % eix gentoo-sources
[D] sys-kernel/gentoo-sources
Available versions:
(3.0.17-r2) 3.0.17-r2^bs
(3.0.35) 3.0.35^bs
(3.0.45) (~)3.0.45^bs
(3.0.46) (~)3.0.46^bs
(3.3.8) 3.3.8^bs
(3.3.8-r1) (~)3.3.8-r1^bs
(3.4.9) 3.4.9^bs
(3.4.10) (~)3.4.10^bs
(3.4.11) (~)3.4.11^bs
(3.5.6) (~)3.5.6^bs
(3.5.7) (~)3.5.7^bs
(3.6.1) (~)3.6.1^bs
(3.6.2) (~)3.6.2^bs
{{build deblob symlink}}
Installed versions: 3.6.0(3.6.0)^bs(10:36:25 AM 10/03/2012)(-build -deblob -symlink) 3.6.1(3.6.1)^bs(10:27:15 AM 10/08/2012)(-build -deblob -symlink) 3.6.2(3.6.2)^bs(12:26:57 PM 10/15/2012)(-build -deblob -symlink)
Homepage: http://dev.gentoo.org/~mpagano/genpatches
Description: Full sources including the Gentoo patchset for the 3.6 kernel treeYMMV.
Gave me some insight..but it will be better if there is a way to change the MAX_*_CONSOLES at runtime.
yea, this is one of those issues that is not really a problem until i run htop and realize that there are many process’es running.