Назад | Перейти на главную страницу

Одно сообщение Dbus запускает несколько сервисов systemd

Как я могу запустить несколько сервисов systemd при запуске сигнала dbus.

Я пытаюсь сделать это для org.freedesktop.hostname1 создавая такую ​​услугу, как:

[Unit]
Description=Set host name

[Service]
ExecStart=/home/administrator/set-hostname
BusName=org.freedesktop.hostname1

После включения и запуска netplan apply сценарий не выполняется.

TA.

Я предполагаю, что, «запуская» службу, вы хотите, чтобы новая служба запустилась (что может сделать systemd) вместо того, чтобы заставлять уже работающую службу что-то делать (что полностью вне досягаемости системы инициализации).

Основы D-Bus

Каждое сообщение D-Bus имеет ровно одно поле «получатель» (которое может быть известным именем, например org.example, уникальное имя, например :1.234, или широковещательный адрес).

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

Автозапуск службы D-Bus

Демон шины автоматически запускает службы, когда:

  1. есть сообщение, отправленное на конкретное известное имя,
  2. и эта известная услуга в настоящее время не востребована в автобусе,
  3. и у этого хорошо известного имени есть соответствующий файл D-Bus .service (не путать с файлами systemd .service) в разделе /usr/share/dbus-1/system-services/.

Из пункта 2 важно отметить, что только одна служба может претендовать на известное имя и получать сообщения, предназначенные для этого имени. Пока реальный systemd-host named уже запущен и потребовал org.freedesktop.hostname1, он получит эти сообщения - другие процессы не могут сделать то же самое.

Тот же пункт №2 также означает, что автозапуск не случится для имен, которые в настоящее время хранятся в службе. Сообщение будет просто доставлено в эту уже работающую службу.

В пункте №3 имя файла должно именно сопоставить известное название автобуса; то есть у вас не может быть нескольких сервисов, конкурирующих за автозапуск под одним именем. Следовательно, что касается dbus-daemon, каждое сообщение может запускать не более одной службы.

Автозапуск через systemd

Если файл .service D-Bus (в / usr / share / dbus-1 /… /) содержит SystemdService= вариант, dbus-daemon попытается запустить эту службу через systemd вместо традиционного разветвления / выполнения всего, что указано в Exec =.

(Часто служба systemd устанавливает псевдоним с именем dbus-[название автобуса].service - это всего лишь соглашение, разрешающее включение / отключение systemctl, и синтаксис не имеет особого значения, кроме этого.)

Поскольку службы systemd могут иметь зависимости, теперь у вас есть обходной путь для ограничения «каждое сообщение может запускать только одну службу»: непосредственно активируемая служба может использовать другие службы в качестве зависимостей. Однако все, что было объяснено ранее, по-прежнему применимо - как только «настоящая» служба будет запущена, дальнейшие сообщения будут поступать к ней напрямую и не будут запускать автоматический запуск.

Вывод

Похоже, вы пытаетесь полностью избежать systemd-host named, и всякий раз, когда netplan вызывает host named SetHostname() метод, вы хотите, чтобы ваша собственная программа принимала его.

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

Но это является возможно в целом - если вы используете язык программирования, который имеет модуль D-Bus. Вам «просто» нужно подключиться к системной шине, потребовать имя, получать сообщения и обрабатывать их так же, как это делает systemd-host named. Многие модули dbus поставляются с примерами «скелета службы D-Bus».

(На самом деле уже существуют сторонние реализации различных демонов systemd, например LoginKit, systembsd, systemd-shim.)