[Jack-Devel] Some observations re Jack and systemd

[Jörn Nettingsmeier]

Hi everyone,


after scratching my head for a long time to make systemd behave when 
running jack as a service, I thought I'd share my findings:

Example service file:

[Unit]
Description=JACK Audio Connection Kit
After=sound.target
After=ntp.service
After=time-sync.target
Before=jackd.target
Requires=jackd.target

[Service]
EnvironmentFile=-/your/config/file/containing/JACKD_OPTIONS
LimitRTPRIO=85
LimitMEMLOCK=700000000
User=nettings
Environment="DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket"
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/jackd $JACKD_OPTIONS
RestartSec=5
Restart=on-failure

[Install]
WantedBy=multi-user.target


So it's easy to start a service as a user, but that user's environment 
is not automatically pulled in. That means even though user nettings 
does have the necessary permissions in /etc/security/limits.conf, you 
still need to spell them out for systemd.

Another thing to note is that at least on current raspbian, the 
time-sync.target is broken. Its promise is to only be triggered after 
ntp has worked its magic and the system time is monotonous. However, 
I've seen time jumps which combined with cheap USB hardware or the 
builtin Raspi sound will hang jack. Hence the ugly sleep.

Final goodness: systemd might try to clean up after you. So when you 
have a jackd service started in your name, all is well, until you have 
logged in somehow and then closed the last shell, at which point the 
janitor from hell will happily clear /dev/shm and with it all your jack 
semaphores, leading to instant dumpster fire and silence.

This magic can be avoided by setting
RemoveIPC=no
in /etc/systemd/logind.conf

After clearing these hurdles, I've been quite happy with how systemd 
handles jack clients.  The usecase here is a number of clients running 
in an embedded appliance, and systemd takes care of restoring them when 
I cause them to crash, which is good. Not that they crash, but it's good 
to have defense in depth.
Figuring out how to order services is hard because you cannot assume a 
service is really ready when systemd has fired it off. So I've used a 
ExecStartPre script that blocks until a downstream jack port has 
appeared in those cases where I want to start clients in a particular 
order (matters most for the one job that needs to connect all the ports, 
so I let it wait on a test port for each client it needs to connect).

Old-time SysV user here, and granted, systemd has given me many a WTF 
moment, but it does its job. Unfortunately, it does too many other jobs 
as well, but hey...


-- 
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net