me.neoascetic

Что за хрень этот ваш ConsoleKit?

Детективная история о том, откуда у ConsoleKit ноги растут, почему он плодит так много процессов и как заставить его работать после переустановки.

Работает - не трогай. Но я тронул. Потому что однажды открыл htop и увидел 100500 процессов console-kit-daemon, и это меня напугало/удивило/расстроило. Что это за зверь такой, что плодится как вышедшие из-под контроля наноботы? Хорошо хоть (вроде как) ресурсы в серую слизь не превращает.

Первым решением был снос этого зверя из системы. От него зависел (у меня, так как большая часть окружения - не гномовская) только gnome-network-manager, но это не было большой проблемой. Вместо него заюзал wicd, который имеет гораздо больше преимуществ и похорошел с момента нашей последней встречи. В частности, подключается к сетям при старте системы, то есть Wi-Fi доступен и без иксов, а GUI - это лишь GUI, надстройка над консольным интерфейсом, от которого можно отказаться в пользу ncurses-интерфейса, в отличии от network-manager. Короче, снёс без проблем consolekit, а wicd оказался приятным бонусом.

Тут-то и начались проблемы. Мой менеджер питания xfce-power-manager в вопросах гибернации/саспенда мог работать только через этот самый consolekit, без него соответствующие пункты меню недоступны, автоматически при малом заряде батарее триггеры тоже, естественно, не срабатывают. Т. к. без менеджера питания работа с ноутбуком весьма неудобна, начал искать альтернативы, но оптимальных не нашёл. Да, в качестве иконки можно было продолжать пользоваться им, а триггеры (на закрытие крышки, например) навесить, используя acpid, но плясать с бубном и иметь стопицот пакетов в системе не хотелось. Поэтому - решил вернуть consolekit.

Ноу проблем, sudo aptitude install consolekit. Рестарт, и… nothing happens. WTF? Методом долгого и нудного гугления и нескольких перезагрузок определил, что дело в одной строчке в сервис-файлах pam. Почему это не делается автоматически? Я не знаю, возможно из-за вопросов безопасности.

Итак, в конец /etc/pam.d/common-session, где указывается список session-related модулей, необходимо добавить consolekit-коннектор:

; /etc/pam.d/common-session
session optional pam_ck_connector.so nox11

После этого гибернация/саспенд и автомонтирование флешек заработали. Возможно, эту процедуру придется повторить при убновлении PAM, если затрутся конфиги.

Но решение проблемы меня не успокоило, и я продолжил разбираться, что же это за зверь такой - consolekit? На официальном сайте в секции “about” говорится:

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.

При этом под заголовком “Defining the Problem” написано только “To be written”. Уже несколько лет. Проблема высосана из пальца? Я не знаю, я не гуру. Но видео с неким товарищем, который рассказывает, что нынешние решения для десктопа sucks, и показывает, в частности, как лажает в плане безопасности ConsoleKit, интересно и рекомендовано к просмотру.

Ладно, подумал я, миллионы мух не могут ошибаться, раз этот consolekit используется в важных для меня софтинах - значит, он нужен. Хоть и не нужен. Но, черт возьми, какого хрена он кантует мои нервы, создавая кучу процессов? Может, есть где-нибудь в конфигах параметр, указывающий, сколько максимум процессов плодить? Но /etc/default/consolekit, /etc/consolekit или что-то подобное отсутствовали.

Бред какой-то, подумал я. И сделал grep /usr -i ConsoleKit. Нашёл это:

; /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
[D-BUS Service]
Name=org.freedesktop.ConsoleKit
Exec=/usr/sbin/console-kit-daemon --no-daemon
User=root
SystemdService=console-kit-daemon.service

Ммм, как гениально, подумал я. Мы запускаем сервис (сиречь демон) с флагом --no-daemon. Так и надо? Или я чего-то не понимаю? Ладно, по идее, если убрать этот флаг, плодиться процессы больше не должны, должен остаться лишь один демон, который и будет обслуживать все запросы, так?

Не тут-то было. Все осталось по-прежнему - куча процессов, висящих и чего-то ждущих.

Ок, идём дальше. Значение параметра SystemdService выглядит как имя файла. Имя сервиса в systemd, который является заменой System V init, то есть процесс, запускающий все остальные процессы и демоны, или систему.

Содержимое /lib/systemd/system/console-kit-daemon.service:

; /lib/systemd/system/console-kit-daemon.service
[Unit]
Description=Console Manager
After=syslog.target

[Service]
Type=dbus
BusName=org.freedesktop.ConsoleKit
ExecStart=/usr/sbin/console-kit-daemon --no-daemon

Что?! Имя dbus-шины? И снова путь к исполняемому файлу с тем же флагом? Черт возьми, что твориться? Круговая порука? Я совсем запутался, где курица, а где яйцо.

Было поздно. Я устал. Опытные товарищи сказали мне, что есть вещи… в которые лучше не лезть, и высший дзен - “работает - не трогай”. Я попытался убрать флаг здесь, потом здесь и в файле dbus, но ничего не помогло избавиться мне от кучи процессов.

А потом я прочёл, что все эти процессы - суть нити. Включил “Hide userland threads” в htop, и успокоился.