служба не работает шина процессы

Служба не занимает имя на шине: оно уже занято

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

Вероятные причины

По порядку: сверху то, что встречается чаще.

Второй экземпляр службы уже работает

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

Ручной запуск оставляет процесс вне управления systemd. Он занимает имя, а служба менеджера не может работать.
Права на шине не дают занять имя

Занятие имени на системной шине разрешается правилами. Без разрешения служба получает отказ.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Занятые имена на шине и процессы-владельцы.

busctl list 2>/dev/null | head -20

Сообщение службы о попытке занять имя.

journalctl -u myapp.service -n 20 --no-pager

Процессы под управлением службы.

systemd-cgls -u myapp.service 2>/dev/null

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Второй экземпляр службы уже работает

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

Как проверить

Посмотрите владельца имени и процессы.

busctl list 2>/dev/null | grep -i myapp
pgrep -a myapp | head

Как исправить: Остановите лишний экземпляр. Проверить, кто держит имя, можно в списке имён на шине: там указан процесс.

2. Служба запущена и вручную, и через менеджер

Почему происходит: Ручной запуск оставляет процесс вне управления systemd. Он занимает имя, а служба менеджера не может работать.

Как проверить

Посмотрите, какие процессы вне среза службы.

systemd-cgls -u myapp.service 2>/dev/null | head
pgrep -a myapp | head

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

3. Права на шине не дают занять имя

Почему происходит: Занятие имени на системной шине разрешается правилами. Без разрешения служба получает отказ.

Как проверить

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

sudo grep -rl "org.example.MyApp" /usr/share/dbus-1/system.d/ /etc/dbus-1/system.d/ 2>/dev/null
journalctl -u myapp.service -n 20 --no-pager | grep -i "own name"

Как исправить: Добавьте правило, разрешающее пользователю службы занимать своё имя. Правила лежат в каталогах настроек шины.

Пример вывода

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

myapp[11300]: Failed to request name on bus: Request to own name refused by policy (already owned by :1.42)
myapp[11300]: fatal: cannot export D-Bus interface
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

Failed to connect to bus: подключение к шине недоступно Команды systemctl не работают: нет подключения к шине. Разбор для контейнеров, сеансов по ssh и служб пользователя.
Address already in use при запуске службы Порт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
supervisord под systemd: два надзорщика за одними процессами Процессы перезапускаются дважды или не перезапускаются вовсе: systemd и supervisord следят за одним и тем же.
No such process при остановке или сигнале Ошибка 3: процесса с таким номером нет. Разбор для команд остановки и подстановки номера процесса.
Too many tasks: упор в предел TasksMax Служба не может создать новый процесс: достигнут предел TasksMax. Где он задан и как поднять правильно.
Процессы вне служб: области и потерянные процессы Процессы работают вне unit: запущены из терминала или сеанса. Почему systemd их не перезапускает и как перевести.
Служба не создаёт потоки: упор в предел Ошибка создания потока: исчерпан TasksMax или системный предел процессов. Как посчитать нужное значение.
AppArmor: apparmor="DENIED" в журнале ядра Профиль AppArmor запретил операцию: как прочитать запись, найти профиль и поправить его правильно.

Источники

dbus-daemon(1)
Имена на шине и правила их занятия. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено вторым экземпляром службы с тем же именем на шине. собственная проверка, systemd 255
сверено 15 сентября 2026