Ubuntu dbus что это

Ubuntu dbus что это

Библиотека сайта rus-linux.net

Пакет D-BUS-1.4.16

Знакомимся с пакетом D-BUS

D-BUS является системой шины сообщений, предлагающей приложениям простой способ обмена сообщениями. В составе D-BUS есть как системный демон (для таких событий, как «добавлено новое устройство» или «изменена очередь печати»), так и демон, запускаемый при регистрации в системе каждой новой сессии пользователя (для обычного межпроцессного обмена сообщениями между приложениями пользователя). Кроме того, шина сообщений собирается поверх фреймворка, предназначенного для передачи сообщений вида 1:1 и который может использоваться любыми двумя приложениям для непосредственного взаимодействия друг с другом (минуя демон шины обмена сообщениями).

Известно, что пакет правильно собирается и работает на платформе LFS-7.0.

Информация о пакете

Зависимости пакета D-BUS

Обязательные

Необязательные

Xorg Libraries, D-Bus GLib Bindings-0.98 (для запуска тестов) и Doxygen-1.7.2 (для создания документации по API)

Обратите внимание, что скрипт configure похож на скрипт пакета xmlto-0.0.23, но ничего не делает, т.к. документация XML/HTML уже есть в дереве с исходным кодом.

Конфигурирование ядра

Обеспечьте, чтобы следующий параметр был включен в конфигурации ядра, и перекомпилируйте ядро, если это необходимо:

Установка пакета D-BUS

В роли пользователя root создайте системного пользователя и группу, предназначенные для доступа к шине системных сообщений:

Инструкции по тестированию приведены ниже.

Теперь в роли пользователя root выполните:

Обратите внимание, что если тесты запускаются внутри оболочки Midnight Commander, будет выдано сообщение о том, что они, возможно, не прошли.

Пояснение команд

—enable-tests : Строит дополнительные пути, используемые при тестировании кода. Конфигурирование заканчивается выдачей замечания, сообщающего об этом.

—disable-static : Предотвращает сборку и установку статических библиотек.

Конфигурирование пакета dbus

Конфигурационные файлы

Подробнее о конфигурировании

Конфигурационные файлы, указанные выше, по-видимому, менять не нужно. Если изменения необходимы, вы должны создать файл /etc/dbus-1/session-local.conf и/или файл /etc/dbus-1/system-local.conf и внести в них необходимые изменения.

Загрузочный скрипт

Заметим, что это в загрузочном скрипте запускается только общесистемный демон D-BUS. Каждому пользователю, которому требуется доступ к сервисам D-BUS, нужно будет также запустить сессионный демон. Есть много вариантов запуска сессионного демона с помощью команды dbus-launch. Подробности об имеющихся параметрах и возможностях смотрите на странице man команды dbus-launch. Вот некоторые предложения и примеры:

/.xinitrc строчку с командой dbus-launch в строку файла

/.xsession строчку с командой dbus-launch, которая будет запускать графическую среду вашего рабочего стола. Синтаксис аналогичен примеру, приведенному в файле

В этом случае сессионый демон не останавливается, когда вы выходите из командной оболочки, так что вы должны в ваш файл

/.bash_logout добавить следующую строку:

Описание пакета

Установленные программы: dbus-cleanup-sockets, dbus-daemon, dbus-daemon-launch-helper, dbus-launch, dbus-monitor, dbus-send, and dbus-uuidgen

Установленные библиотеки: libdbus-1.

используется для очистки директория от остатков сокетов

является демоном шины сообщений D-BUS

используется для запуска dbus-daemon из скрипта командной оболочки. Как правило, вызывается из скриптов, регистрирующих вход пользователей в систему

используется для мониторинга сообщений, поступающих через шину сообщений D-BUS

используется для отправки сообщения в шину сообщений D-BUS

используется для создания или чтения универсального уникального идентификатора

содержит функции API, используемые демоном сообщений D-BUS. D-BUS является первой библиотекой, в которой предложены средства обмена сообщениями вида 1:1 между двумя любыми приложениями; dbus-daemon является приложением, использующим эту библиотеку для реализации демона шины сообщений

Перевод сделан с варианта оригинала, датированного 2011-12-16 19:54:18 +0000

Источник

Управление Linux десктопом через D-Bus

Используя D-Bus, вы можете персонализировать и автоматизировать ваш десктоп.

Каждая современная Linux среда рабочего стола использует D-Bus, систему, позволяющую программным приложениям общаться друг с другом. Благодаря D-Bus, ваш десктоп может быть настроен точно так, как вы хотите. В этой статье я привожу примеры некоторых возможностей D-Dus. Будьте готовы к модификации вашего десктопа.

D-Bus регистрирует каждую программу, имеющую сервисы, доступные для других приложений. Таким образом, эти приложения видят, какие сервисы доступны. Также, программы могут становиться доступными для событий системных сервисов (например, определять горячую замену железа).

D-Bus не разрешает прямую коммуникацию между процессами, а работает через шину. Системная шина обеспечивает маршрутизацию сообщений между процессами через себя, таким образом, процессы могут взаимодействовать с несколькими приложениями одновременно. Каждое приложение может посылать сообщения на шину или реагировать на события, получаемые через шину.

Работа с D-Bus

Итак, как же можно использовать D-Bus в своем собственном приложении? Основной API написан на С довольно низкого уровня. Он не задумывался для использования программистами приложений. Различные языки программирования и среды разработки, такие как GLib, Qt, Python, Ruby, Perl и Mono имеют надстроенные над этим API связующие слои. Я не буду углубляться в С или GLib (основаная библиотека в GNOME), но я приведу несколько примеров, написанных на скриптовых языках Python и Ruby, а так же примеры скриптов командной оболочки.

Какие приложения используют D-Bus?

Рисунок 1. QDBusViewer работающий в GNOME

Стоит упомянуть, что qdbusviewer показывает только имена сервисов, зарегистрированных на текущий момент. Например, если Pidgin не запущен, то программа просмотра не будет его отображать. Имейте это ввиду, исследуя D-Bus сервисы, доступные в вашей системе.

Мы получим тот же самый список из методов и интерфейсов, что мы видели в qdbusviewer. Например, строку:

method bool org.freedesktop.PowerManagement.GetOnBattery()

Также qdbus позволяет нам вызывать эти методы напрямую. Например, если мы хотим вызвать метод Suspend, выполняем:

Работаем с D-Bus из командной строки

В оставшейся части статьи мы рассмотрим D-Bus функциональность некоторых популярных приложений, а также напишем скрипты для взаимодействия с этими приложениями и автоматизации ряда задач. Надеюсь, это вдохновит вас на взаимодействие с вашими собственными любимыми приложениями. Я буду использовать разные D-Bus инструменты и скриптовые языки для демонстрации различных способов работы с D-Bus.

Я уже упомянул первый способ работы с D-Bus: использование KDE программ qdbusviewer и qdbus. Если вы не работаете в KDE, то можете использовать программы командной строки dbus-send и dbus-monitor, для отсылки и мониторинга D-Bus сообщений, соответственно. Например, вы можете отправить систему в спящий режим, следующей командой:

С помощью этих двух команд, мы можем создать свой собственный скрипт командной оболочки для скринсейвера. Примечание: во время запуска первой команды вы должны сохранить куки в переменную или в файл, а затем заменить значение куки в команде, что выше.

Если вы отлаживаете D-Bus скрипт или наблюдаете за методами и сигналами других D-Bus приложений, то программа командной строки dbus-monitor очень вам в этом поможет. Просто запустите ее через терминал, и вы увидите всю D-Bus активность. dbus-monitor полезен для просмотра D-Bus активности в реальном времени. Если с вашей системой что-то происходит, например пропадает сеть, то на выходе dbus-monitor вы можете видеть как это сообщение поступает на шину D-Bus. Таким образом вы можете узнать какие сигналы или методы должны использоваться для работы с тем или иным событием.

dbus-monitor так же позволяет вам указать ряд выражений, определяющих за чем вы хотите наблюдать, например:

Пишем скрипт для чтения Liferea ленты

Liferea предоставляет скрипт, который делает точно тоже самое, но еще умеет обрабатывать ошибки.

Без клавиатуры

Если вы хотите выполнить более сложные задания, чем вызов отдельных методов, то вы можете написать скрипт командной оболочки, содержащий dbus-send команды, или используйте язык более высокого уровня, для упрощения задачи. Существуют D-Bus привязки для Python, Ruby и Java языков.

В следующем примере, я реализую скрипт на Python, который меняет ваш статус в Pidgin на “Away from keyboard”, при активизации скринсейвера. Здесь имеются два аспекта D-Bus: скрипт ждет сигнала от скринсейвера, и затем он вызывает метод в Pidgin. Скрипт показан в листинге 1.

Листинг 1. pidgin_screensaver.py

Далее функция проверяет переменную state, которая является аргументом функции pidgin_status_func (я объясню, что означает этот аргумент далее). Если аргумент правдив, то сообщению нового статуса “afk” присваивается значение “Away from keyboard”, и статус активируется. В результате Pidgin показывает ваш статус как “afk», с сообщением “Away from keyboard”.

Pidgin имеет очень обширный D-Bus интерфейс; вы можете делать с помощью него практически все. Пусть этот пример послужит вам вдохновением для создания каких-нибудь креативных задач в Pidgin!

Проигрывание с помощью D-Bus

Давайте посмотрим на другой пример, на этот раз на Ruby. Мы создадим скрипт, который будет показывать текущую песню, играющую в Rhythmbox, вместо вашего статуса в Pidgin (Листинг 2).

Листинг 2. pidgin_rhythmbox.rb

Здесь мы видим команды такого же типа, как и в скрипте на Python: начинаем D-Bus сессию, определяем D-Bus сервис, объекты и интерфейс, и определяем приемник сигнала. Цикл постоянно работает для прослушивания D-Bus сигнала.
Конечно, все это можно немного привести в порядок. Например, на данный момент, в качестве статусного сообщения мы показываем только путь к файлу песни. Я предоставляю вам возможность самим заменить путь к файлу на соответствующий ID3 тег.

Заключение

Приложение

Источник

Русские Блоги

Подробно о D-Bus: от компиляции к приложению

1. Введение

С архитектурной точки зрения он разделен на три слоя:

Libdbus поддерживает только однозначные соединения, как и необработанные сетевые сокеты. Но вместо того, чтобы отправлять поток байтов через соединение, он отправляет сообщение. Сообщение имеет заголовок, который определяет тип сообщения, и тело, содержащее полезные данные. Libdbus также абстрагирует используемый метод передачи данных (сокеты и другие методы) и обрабатывает такие детали, как аутентификация.

Демон шины сообщений образует концентратор. Каждый концентратор концентратора использует libdbus для индивидуального подключения к приложению. Приложение отправляет сообщение демону шины через свою ветку, а затем демон шины пересылает сообщение другим подключенным приложениям. Вы можете думать о демоне как о маршрутизаторе.

Реализация низкоуровневого API dbus и протокола D-Bus тщательно тестировалась в течение нескольких лет и сейчас «завершена». Будущие изменения будут совместимы или версированы соответствующим образом.

Следует отметить, что основная реализация не предназначена в первую очередь для авторов приложений. Напротив, это основание для ограничения автора и ссылка на повторную реализацию. Если возможно, рекомендуется использовать одну из привязок или реализаций более высокого уровня.

D-Bus может быть легко перенесен на любую версию Linux или UNIX, и в настоящее время переносится на Windows.

2. Коммуникационные характеристики

Три, скачать

Эталонная реализация

ТекущийстабильныйФилиалDBUS 1.12.x. Это рекомендуемая версия.

В настоящее времятрадиционныйОтветвлятьсяDBUS 1.10.x. Поддержка по-прежнему предоставляется, но только для исправлений безопасности.

Срок действия более старых веток (таких как 1.8.x и 1.6.x) истек, и маловероятно, что будут выпущены другие версии.

ТекущийРазработкаФилиалdbus 1.13.x, Это сформирует стабильную ветку 1.14.x. В ветке разработки нет поддержки безопасности, и эта версия также содержит изменения, которые могут дестабилизировать.

Замененные ветки разработки, такие как 1.11.x и 1.9.x, вообще не поддерживаются, и в будущем исправлений безопасности не будет.

Связывание и независимая реализация

Связывание и независимая реализация отBindings Pageподключен к.

Привязка обертывает libdbus (и, следовательно, автоматически получает новый механизм аутентификации и другие дополнения к libdbus), в то время как повторная реализация кодирует протокол с нуля (таким образом избегая зависимости от библиотеки libdbus C, но должна быть объединена с новой функцией Stay в синхронизации).

Исходный код

Проект на экземпляре Freedesktop.org Gitlab dbus Последняя версия и эталонная реализация спецификации D-Bus доступны в формате.

Для других реализаций и привязок используйте репозиторий исходного кода для достижения соответствующей реализации.

Четыре, скомпилировать

Установить cmake

Непосредственно sudo apt-get install cmake под Ubuntu имеет более низкую версию.

Подсказка Требуется CMake 3.0.2 или выше.

Загрузите последнюю версию 3.17.1 с официального сайта, затем распакуйте и скомпилируйте

Установить экспат

Официальный сайт: https://libexpat.github.io/

Установить dbus

В качестве примера возьмем версию dbus-1.12.16.

Разархивируйте исходный код после загрузки

Примечание: Компиляция версии 1.8.X несовместима с 1.12.16:

Введение в сгенерированный bin-файл

dbus-cleanup-sockets: Используется для очистки оставшихся сокетов в каталоге.

dbus-daemon: Это демон шины сообщений D-Bus.

dbus-launch: Используется для запуска из сценария оболочкиdbus-daemon. Обычно он вызывается из сценария входа пользователя.

dbus-monitor: Используется для отслеживания сообщений, проходящих через шину сообщений D-Bus.

dbus-run-session: Запустить процесс как новый сеанс D-Bus.

dbus-send: Используется для отправки сообщений на шину сообщений D-Bus.

dbus-test-tool: Это генератор трафика D-Bus и инструмент для тестирования, это многофункциональный инструмент для отладки и анализа D-Bus.

dbus-uuidgen: Используется для создания универсального уникального идентификатора.

Пять, руководство по API

Справочное руководство по API, используемое для ссылки на реализацию libdbus: http://dbus.freedesktop.org/doc/api/html/index.html

Шесть, техническая реализация

Сам D-Bus построен на механизме Socket. Настоящее общение по-прежнему осуществляется Socket. D-Bus находится на вершине этого, формулируя некоторые протоколы связи и предоставляя интерфейс более высокого уровня для облегчения взаимодействия данных между приложениями.

В системе D-Bus есть резидентный демон процесса, через который распределяются и управляются все взаимодействия между процессами. Все процессы, которые хотят использовать D-Bus для связи, должны заранее подключиться к Daemon и зарегистрировать свое имя в Daemon.После этого Daemon будет отправлять сообщения и данные соответствующему процессу по мере необходимости.

На машине есть несколько экземпляров автобуса. Эти автобусы независимы друг от друга. Постоянная системная шина и множество сессионных шин.

Приложение в основном включает в себя два аспекта: вызов функции и рассылку сообщений.

1. Основные концепции

Address

адрес используется для идентификации dbus-daemon. Когда запускается dbus-daemon, то, как другие приложения должны подключаться к этому dbus-daemon, зависит от адреса.

Формат адреса должен быть таким: unix:path=/var/run/dbus/system_bus_socket 。

Bus Name

Он используется каждым приложением (или партнером по коммуникации) для идентификации себя.

Правила именования для Bus Name следующие:

Имя D-Bus используется для идентификации себя для приложения, поэтому всякий раз, когда программа подключается к демону D-Bus, ей будет назначено уникальное имя, и приложение также может попросить себя назначить другое известное имя (через функция dbus_bus_request_name).

Interface Name

D-Bus также имеет концепцию интерфейса, которая в основном предназначена для использования фреймворков более высокого уровня. На уровне C API вы можете почти игнорировать эту концепцию. Вам нужно знать только эту «строку», и она используется D-Bus при сопоставлении сообщения. Она будет передана другим процессам вместе с сообщением, и отправлено из процесса A. Когда сообщение или данные отправляются процессу B, должна быть часть с этой строкой, в зависимости от того, как процесс B использует ее (или игнорирует). Его правило именования почти такое же, как и для имени D-Bus. Следует отметить только одно, что имя интерфейса не может содержать символов «-».

Object Path

Пример: / com / example / MusicPlayer1

Member Name

Во многом они практически одинаковы, за исключением двух пунктов:

Правило именования имени члена выглядит следующим образом:

2. Обзор процесса коммуникации.

Процесс 1 (Process1) необходимо сначала подключить к шине (dbus_bus_get), затем создать сообщение (dbus_message_new_signal), а затем отправить сообщение (dbus_connection_send) фоновому процессу. Фоновый процесс получает сообщение, а затем обрабатывает его по-разному в зависимости от типа сообщения (bus_dispatch_matches).

Процесс 2 (Process2) должен подключиться к шине до получения сообщения и проинформировать шину о типе сообщения (dbus_bus_add_match), которое он хочет получить, а затем дождаться получения сообщения (dbus_connection_pop_message). Когда процесс 2 (Process2) получает сообщение, пересылаемое шиной, он будет выполнять различную обработку в зависимости от типа сообщения (если это тип сигнала, ему не нужно отправлять возвращаемое значение на шину).

3. Подключитесь к шине

Связанный интерфейс

Пример реализации

Позвольте приложению и D-Bus установить соединение. DBUS_BUS_SESSION указывает, что используется шина сеанса.

После этого воспользуйтесь функцией:

Зарегистрируйте собственное имя процесса в Daemon. DBUS_NAME_FLAG_REPLACE_EXISTING означает использование программы имени шины, если она уже существует, и запрос на замену текущего главного владельца.

4. Соберите данные

Связанный интерфейс

Пример реализации

Как упоминалось выше, в dbus есть четыре типа сообщений.

Сообщение о вызове метода:

Сообщение о возврате метода:

Сообщение об ошибке:

Согласно синтаксису, приведенному в спецификации D-Bus, имя ошибки должно быть допустимым именем ошибки.

Если вы не хотите изменять название ошибки, используйте DBUS_ERROR_FAILED «org.freedesktop.DBus.Error.Failed»

Сигнальное сообщение:

DBus предоставляет тип DBusMessageIter, используя этот тип переменной, мы можем легко добавлять данные в DBusMessage и легко извлекать из него данные.

Функция dbus_message_iter_append_basic добавляет некоторые «базовые» данные в DBusMessageIter. Так называемый базовый тип данных определяется в DBus следующим образом:

Построение структурированного сообщения

Пожалуйста, обратитесь к следующему API, чтобы узнать, как удобно передавать структурное сообщение.

интерфейс:

Пример:

Примечание: передаваемые данные должны быть адресом указателя.

5. Отправьте данные

Связанный интерфейс

Пример реализации

Отправить возврат метода / сигнал / данные об ошибке

Отправьте данные вызова метода и дождитесь ответа:

6. Получать данные

Связанный интерфейс

Пример реализации

Сообщение Signal использует функцию dbus_bus_add_match, чтобы добавить соответствующий сигнал к Daemon, чтобы дать Daemon знать, что он заинтересован в этом сигнале.

Вы можете использовать следующую функцию для ожидания:

После отправки сообщения соответствующие данные могут быть получены через msg.

К ответному сообщению метода:

После этого можно будет провести анализ данных.

7. Анализируйте данные.

Связанный интерфейс

Пример реализации

Оценка сообщения:

Используйте dbus_message_is_signal / dbus_message_is_method_call, чтобы определить тип сообщения.

Анализ сообщений:

Сначала используйте dbus_messge_iter_init, чтобы связать объект DBusMessage с сообщением, полученным с шины DBus.

Таким образом, используйте функцию в 1, чтобы сначала получить тип первого параметра в первых данных связи, и если тип правильный, вы можете использовать функцию в 2, чтобы получить само значение параметра.

Используйте dbus_message_iter_next, чтобы перебрать следующий параметр и повторить вышеуказанные шаги.

Анализ структуры сообщения

Пожалуйста, обратитесь к следующему API, чтобы узнать, как удобно анализировать сообщение структуры.

интерфейс:

Пример:

Примечание: передаваемые данные должны быть адресом указателя.

Семь, профиль разрешения

Файл конфигурации D-Bus Файл конфигурации демона сообщений D-Bus настраивает тип шины, ограничения ресурсов и параметры безопасности. Формат файла конфигурации не является частью стандарта, и обратная совместимость не гарантируется.

Стандартная системная шина и сессионная шина находятся в «/etc/dbus-1/system.conf» и «/etc/dbus-1/session.conf» (1.12.16 в «/share/dbus-1/system.conf» «И» /share/dbus-1/session.conf «).

Перечисленные выше файлы конфигурации нельзя изменять. Если вам нужно его изменить, вы должны создать /etc/dbus-1/session-local.conf и / или /etc/dbus-1/system-local.conf Внесите в эти файлы необходимые изменения.

В основном это система или сессия.

Включите все файлы конфигурации в каталог в текущем расположении. Порядок, в котором файлы включаются в каталог, не фиксирован, и будут включены только файлы, заканчивающиеся на «.conf».

Пользователь, которого запускает демон, может быть именем пользователя или uid. Если демон не может переключиться на этого пользователя, он автоматически завершит работу. Если имеется несколько элементов конфигурации, будет использоваться последний из них.

Процесс становится настоящим демоном.

Если существует, демон сохранит исходную umask при выполнении вилки.

Укажите механизм авторизации. Если его нет, разрешены все известные механизмы. Если существует несколько конфигураций, разрешены все перечисленные механизмы.

эквивалентен установке серии элементов,“XDG Base Directory Specification”

Установите помощник setuid, используйте установленного пользователя для запуска процесса демона системной службы, вообще говоря, это должен быть dbus-daemon-launch-helper. Эта опция используется только для системной шины.

Ограничения ресурсов обычно используются для системных шин. Установите ограничения ресурсов, например:

Доступные ограниченные имена:

Определите политику безопасности для набора конкретных соединений, из которых состоит политика и элементы. Эта стратегия обычно используется на системной шине, имитируя функцию межсетевого экрана, чтобы разрешить только ожидаемые соединения. Политика по умолчанию для текущей системной шины предотвращает отправку вызовов методов и получение имен шин, а другие вещи, такие как ответы на сообщения и сигналы, разрешены по умолчанию.

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

Элемент может иметь один из следующих четырех атрибутов: context = ”(по умолчанию | обязательный)” at_console = ”(true | false)” user = ”имя пользователя или идентификатор пользователя” group = “имя группы или gid”

Политика применяется к соединению по следующим правилам:

И появиться под элементом, запретить некоторые действия и создать некоторые исключения для указанного выше элемента. Атрибуты, доступные для этих двух элементов, включают:

send_destination и receive_sender относятся к владельцу, адресат которого получен или получен от имени, а не имени. Следовательно, если соединение имеет три службы A, B и C, если оно отказывается отправлять в A, то отправка в B и C также не будет работать. другие send_* с receive_* Сопоставьте поля заголовка сообщения.

Как видите, по умолчанию отправка всех сообщений разрешена.

Восемь, демон сеанса D-Bus

Файл конфигурации, используемый экземпляром системы = / etc / dbus-1 / system.conf

Файл конфигурации, используемый экземпляром сеанса = / etc / dbus-1 / session.conf

Вообще говоря, системный демон, запускаемый сценарием инициализации, имеет полномочия root, и большинство его функций используется для трансляции системных событий, таких как подключение и отключение устройств. Демон сеанса используется для взаимодействия процессов между разными рабочими столами или между разными процессами.

Параметры команды

Приоритет этих параметров настройки выше, чем заданный в файле конфигурации.

-Сессия: для каждого пользователя, вошедшего в систему, обычный пользователь (демон dbus с обычными полномочиями)

-Система: для системных пользователей, суперполномочия (привилегированный демон dbus)

—Config-file = FILE: укажите расположение файла конфигурации, связанного с демоном dbus.

-Fork: разрешить демону dbus разветвить процесс

-Нофорк: вилка не требуется

-Print-address [= DESCRIPTOR]: распечатать адрес прослушивания демона dbus.

–Print-pid [= DESCRIPTOR]: распечатать pid демона dbus

—Introspect: распечатать внутренний метод реализации демона dbus

–Address: установить адрес прослушивания.

—Nopidfile: не записывать pid в файл (файл конфигурации настроит файл для записи pid демона dbus)

—Systemd-Activation: может быть связано со службой запуска systemd.

-Syslog: заставить демон dbus использовать системный журнал (то есть журнал будет записываться и выводиться на стандартный вывод)

–Syslog-only: делать только syslog

-Nosyslog: делать только стандартный вывод

пример

Откройте тип сеанса dbus-daemon, распечатайте адрес прослушивания, распечатайте pid и не выполняйте вилку

Распечатайте все методы внутри демона dbus

Укажите адрес прослушивания

ботинок

Для автоматического запуска при перезагрузке системыdbus-daemon,Пожалуйста /etc/rc.d/init.d/dbus Изblfs-bootscripts-20200404Инструкция по установке в пакетесценарий. (Не проверено на практике, только запись для справки, система dbus-daemon уже существует в ARM и Linux)

Обратите внимание, что этот сценарий запуска запускает только общесистемный демон D-Bus. Каждому пользователю, которому необходим доступ к сервису D-Bus, также потребуется запустить демон сеанса. использоватьdbus-launch Команды могут использовать множество методов для запуска демона сеанса, как указано выше.

использоватьdbus-launchУкажите программу для запуска. (Когда также используется параметр * –exit-with-session *) Преимущество этого заключается в том, что когда указанная программа останавливается, демон сеанса останавливается.

Вы также можете запустить демон сеанса в системном или личном сценарии запуска, добавив следующую строку:

При выходе из оболочки этот метод не останавливает демон сеанса, поэтому он должен быть

/.bash_logout Добавьте в файл следующую строку:

Девять, приложение

Полный пример один

Полный код, соответствующий приведенному выше фрагменту реализации:

Отправитель процесс

Процесс приемника

Полный пример два

Это должно быть все, что вам нужно для написания простого сервера и клиента для D-BUS с использованием C API.

Следующий фрагмент кода взят из dbus example.c.

Прием сигнала: dbus-пример получения

Отправить сигнал: параметр отправки dbus-example

Вызов метода прослушивания: dbus-example listen

Метод вызова: параметр запроса dbus-example

Пример компиляции

Компиляция Linux

ARM компиляция

Может быть предложено найти файл заголовка dbus-arch-deps.h в системной lib \ dbus-1.0 \ include, а затем скопировать его в каталог include / dbus-1.0 / dbus.

Меры предосторожности при эксплуатации

Сначала вам нужно запустить dbus-daemon. Проверьте процесс в ARM, следующее уже запущено, иначе вам нужно сначала запустить демон.

Запустить dbus-daemon

Установите переменную среды DBUS_SESSION_BUS_ADDRESS и установите для печатаемого содержимого значение DBUS_SESSION_BUS_ADDRESS, чтобы можно было использовать шину сеанса.

Общее содержание печати:

Чтобы установить переменную среды DBUS_SYSTEM_BUS_ADDRESS, вам необходимо установить содержимое первой половины печати в переменную среды DBUS_SYSTEM_BUS_ADDRESS = unix: path = / var / run / dbus / system_bus_socket, перезапустить устройство или создать файл конфигурации.

Если при работе в ARM появляется запрос, сеанс не запускается и выдается сообщение об ошибке:

Решение относится к ссылке ниже:

Через программу dbus-launch демон для ответа сеанса будет fork, и программа может общаться через этого демона.

Или (я использую это).

Переменная среды DBUS_SESSION_BUS_ADDRESS отображается во время второго выполнения. Затем вы можете запустить программу для подключения к сессионной шине.

Источник