systemd jack autostart

Предполагаю, что что-то с сессией или управлением прав на доступ к устройствам.

Добавь себя в группу audio (usermod -a -G audio alexey), перегрузись и проверь.

(Это костыль исключительно для проверки гипотезы. Если сработает, я порекомендую откатить изменения и запускать твой юнит через systemd --user. В общем, отпишись.)

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

Ясненько.

Ну... а, всё равно попробуй сделать через systemd --user. Если пульса так работает, почему бы jack-у не работать аналогичным образом?

В общем:

• юнит класть в ~/.config/systemd/user/jack.service:

  [Unit]
  Description=JACK
  Wants=sound.target
  After=sound.target
  
  [Service]
  ExecStart=/usr/bin/jackd -R -P89 -d alsa -d hw:DS -r 44100 -p128 -n3
  
  [Install]
  WantedBy=default.target
  

• включать и запускать так (всё от имени юзера, уже залогинившись):

  systemctl --user daemon-reload
  systemctl --user enable jack
  systemctl --user start jack
  

Получилось?

Тебе надо сделать

loginctl enable-linger alexey

enable-linger USER

This allows users who are not logged in to run long-running services.

Я так понял ты используешь systemd user session, у меня два вопроса (оффтоп):

1. Как ты упорядочиваешь сервисы требующие dbus session bus.

2. То же самое про xorg. Пробовал xorg-launch-helper, проблем с юнитами больше чем при синхронном запуске всего с xinitrc (банально быстрей).

Не «session». В этом вся суть. systemd --user имеет полное право запуститься до появления сессии и завершиться сильно после окончания сессии (более того, он запускается один на юзера, а не на каждую сессию).

Если ты говоришь про истинную сессионную шину (которая запускается вместе с иксами), то на этом месте начинаются жутчайшие костыли и полный экспериментал. В моём случае это решается так: https://github.com/intelfx/user-systemd-units (в директории xsession лежит, считай, .xinitrc; дальнейшие вопросы, если есть, на мыло).

Спасибо за ссылку, посмотрю.

Это совершенно не то. Этот параметр нужен, чтобы logind

1. не убивал все процессы сессии, когда юзер разлогинивается (т. е. для screen/tmux);
2. не убивал systemd --user, когда больше сессий юзера не остаётся (когда он разлогинивается в последний раз).

Это совершенно не то

Если и так, то значит в systemd хреновая документация. Ты ведь согласен, что проблема именно в systemd/logind, и уж точно не в jackd?

Это не проблема, а фича. Доступ к звуковым устройствам получает только тот пользователь, чья сессия в настоящий момент активна.

Нашёл похожую тему: https://bbs.archlinux.org/viewtopic.php?id=153527 - там проблема в том, что jackd цепляется к dbus при запуске, и соответственно фейлится будучи запущенным слишком рано. Но в ТС'а другая ситуация - юнит вообще не стартует, значит, «проблемы на вашей стороне», то есть с systemd.

Правду можно узнать только после вывода

systemctl status jackd

mtk

Итак, я поставил jackd и виновато ядро. Сессии и прочее тут вообще ни при чём, юнит ТСа почти рабочий (dbus не должен влиять, т. к. он сокет-активируемый).

ТС, проблема в том, что jackd у тебя хочет реалтайма. Решение описано здесь и оно таково:

...
[Service]
LimitRTPRIO=infinity
LimitMEMLOCK=infinity
...

Я проверил у себя — работает.

Спасибо, сейчас не дома, проверю, отпишусь

может не в тему - systemctl daemon-reload

невышло

● jackd.service - JACK
   Loaded: loaded (/etc/systemd/system/jackd.service; enabled)
   Active: failed (Result: exit-code) since Вт 2014-08-26 18:07:57 SAMT; 47s ago
  Process: 232 ExecStart=/usr/bin/jackd -R -P89 -d alsa -d hw:DS -r 44100 -p128 -n3 (code=exited, status=255)
 Main PID: 232 (code=exited, status=255)

авг 26 18:08:03 alexey-desktop jackd[232]: jackdmp comes with ABSOLUTELY NO WARRANTY
авг 26 18:08:03 alexey-desktop jackd[232]: This is free software, and you are welcome to redistribute it
авг 26 18:08:03 alexey-desktop jackd[232]: under certain conditions; see the file COPYING for details
авг 26 18:08:03 alexey-desktop jackd[232]: JACK server starting in realtime mode with priority 89
авг 26 18:08:03 alexey-desktop jackd[232]: self-connect-mode is "Don't restrict self connect requests"
авг 26 18:08:03 alexey-desktop jackd[232]: Failed to connect to session bus for device reservation Unable to autolaunch a dbus-daemon wi... for X11
авг 26 18:08:03 alexey-desktop jackd[232]: Audio device hw:DS cannot be acquired...
авг 26 18:08:03 alexey-desktop jackd[232]: Cannot initialize driver
авг 26 18:08:03 alexey-desktop jackd[232]: JackServer::Open failed with -1
авг 26 18:08:03 alexey-desktop jackd[232]: Failed to open server
Hint: Some lines were ellipsized, use -l to show in full.

Хм. Это jack2. Да, с ним не выходит.

Ему зачем-то нужна сессионная шина D-Bus. Доступ к этой шине есть только у программ, запущенных изнутри иксов, т. е. через .xinitrc.

Доступ к этой шине есть только у программ, запущенных изнутри иксов, т. е. через .xinitrc.

Если точнее, иксы нужны чтобы подцепиться к уже запущенной сессии dbus через dbus-launch --autolaunch. То есть если переменная окружения DBUS_SESSION_BUS_ADDRESS не установлена для приложения, оно пытается прочитать ее значение из текущей сессии иксов (открывая $DISPLAY) или из файла ~/.dbus/session-bus/$machine-id. В момент запуска сервиса jackd ни иксы, ни дубас не запущены, следовательно, он фейлится. Возможно, надо запускать dbus тоже через systemd --user и добавить в jackd.service After=dbus.service.

Как по мне, «агрессивный параллелизм» создает больше проблем, чем решает.

systemctl start jackd.service --user

Пользовательские юниты должны лежать в /etc/systemd/user или ~/.config/systemd/user (как писали выше, положи юнит в ~/.config/systemd/user и убери строку User=alexey).

Даже если запускать jack2 вручную после запуска иксов и сессионной шины, он всё равно фейлится. Видимо, он смотрит только на DBUS_SESSION_BUS_ADDRESS и на DISPLAY (ни одна из этих переменных не задана и не может быть задана для демона, запускающегося через systemd или systemd --user).

ну ладно, неплохо работает через автостарт

Да. Через xinitrc или какой-либо другой внутрииксовый автостарт это делается сейчас лучше всего.

Мдя... Энтерпрайзненько.

ни одна из этих переменных не задана и не может быть задана для демона, запускающегося через systemd или systemd --user

т.е. если я напишу обёртку на баше и руками в ней сделаю export DBUS_SESSION_BUS_ADDRESS=123, systemd каким-то образом помешает и отменит этот экспорт?..

Ему зачем-то нужна сессионная шина D-Bus. Доступ к этой шине есть только у программ, запущенных изнутри иксов, т. е. через .xinitrc.

Нет, не так. Можно подцепиться к D-Bus от пользователя с запущенными иксами даже из терминала. Если есть такой пользователь, конечно.

При запуске демона еще не будет запущен D-Bus и иксы. Читай выше.

Я говорю только про штатный случай. Руками никто не мешает накостылить что угодно.

Я не так выразился. Если вручную указать адрес (DBUS_SESSION_BUS_ADDRESS) — доступ, конечно, будет, но по дефолту этот адрес есть только у тех программ, которые запускаются внутри иксов.

Штатными средствами можно сделать

ExecStartPost=/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=123

Я говорю только про штатный случай. Руками никто не мешает накостылить что угодно.

по дефолту этот адрес есть только у тех программ, которые запускаются внутри иксов

На самом деле, по дефолту этого адреса нет ни у кого. Шина цепляется через /etc/X11/xinit/xinitrc.d/30-dbus при xinit или из самого приложения, если оно может открыть иксы на $DISPLAY (при этом приложению быть запущенным внутри иксов необязательно, достаточно установить DISPLAY).

Только это будет уже не та шина. Тогда будет отдельно сессионная шина, запущенная из иксового xinitrc, и отдельно вот это вот, запущенное через самописный dbus.service.

Да, именно так. По дефолту == как сделано в типичных дистрибутивах.

отдельно сессионная шина, запущенная из иксового xinitrc

предполагается запускать dbus не из xinitrc, а только через dbus.service.

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

Уже проходили; вердикт — systemd не готов к запуску приложений, так или иначе требующих доступа к сессионной шине.