Hi!
I've been for several weeks now playing with Rivendell (on Debian) too
... and I faced the same thing as you comment.
I have (IMHO) solved all jackd / root/non-root issues in a way that I
consider the perfect/definitive one: I run jack IN PROMISCUOUS MODE (a
mode designed, although rarely used by the average user, precisely to
allow multi/cross-user client/server inter-operation/sharing, instead of
jackd's default users compartimentalization. In this mode, as long as
any user is on a given, same, POSIX group, declared as env variable by
the user terminal starting Jackd, their jack-client instances are
user-inter-operable with a common/shared jackd server... ), so, to my
understanding, rivendell setup is a perfect use-case for a
promiscuous-mode jackd deployment... here's what I do:
- Create a Systemd unit (jackd.service), that launches jackd in
promiscuous mode for GID XXX (the unit has environment promiscuous
variable set to GID XXX)
- Where XXX is rivendell group (I also assign statically rivendell user
UID XXX)
- To further ensure that promiscuous environment variable present system
wide, I add it to /etc/environment
- I setup jackd.service unit to be run on boot.. so jackd server,
becomes a system-wide service, reachable to anyone in GID XXX
- I MODIFY rivendell.service systemd unit to be launched/depend on
jackd.service unit so it is started AFTER jackd.
- I add root as memeber of group rivendell (GID XXX) , so rivendell
process, owned by root, can connect to jack service
- I add the normal system user that logs in the terminal, to rivendell
group (GID XXX), allowing him ant his jackd clients to connect to jackd
service.
This way, the jackd stuff is totally and completelly user
transparent/traversal ... rivendell connects to jack just as it starts,
NO NEED to configure anything, it just works.
Logged user starts qjackctl and, tada!... it connects automatically to
the already running jackd server (no need to start jackd from qjackctl!)
Any jackd-client application launched by the user, appears in the
patchbay, and can be connected to/from rivendell (run as root, member of
XXX)... No problems, no issues, no conflicts, everything JUST WORKS
The only little inconvenience here is that, whenever I update rivendell,
the rivendell systemd unit is reinstalled, and I have to modify it again
to make it to 'want' jackd.service.
Hope this helps... If someone is interested on further details on how to
do this, just let me know!
Best regards.
On 6/9/21 7:45 PM, Florent Peyraud wrote:
Hi everyone
I'm currently working on Ubuntu integration of Rivendell, which means
dealing with systemd, pulseaudio and so on...
In order to make caed use pulse alsa plugin, or even jackd, one
solution is to log in as root, which is evil.
The other solution would be to run caed as the logged in user. This is
due to the fact that pulseaudio and jackd daemons are (normally) only
accessible by the same user as the one that launched them. This is
what I tried with this procedure :
---8<---
sudo systemctl edit rivendell
[Service]
User=radio
--->8---
then I start Rivendell with `systemctl start rivendell.service`, which
usually succeed mostly. But caed and/or rdcatchd crash.
I have core dumps but not analyzed it yet. No evidence could be found
in logs. I'll try to dig deeper and let you know if I can find
something but I'm interested in your feedback if you can reproduce it
on another system (centos for instance...).
As far as you know, is there something in rdservice and its children
which definitely need root rights (shared memory or something like
this) ?
Or maybe it could be possible to run rdservice as root, and it could
launch caed as another user ? I think this was done for pypad
components at a certain time (this has been rollbacked IIRC)
Thanks for your feedback
Best Regards
Florent
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
