systemd integration

[dvzrv]

FluidSynth version

1.1.9

Current behavior

fluidsynth is run as a systemd system service

Expected behavior

fluidsynth should really run as a user service

Steps to reproduce

Run systemctl start fluidsynth

Other information

On Arch Linux the packager crafted a fluidsynth systemd system service. However, those are started as root, which is really not a great solution for an automated user service (as it doesn't see the user's JACK server).

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel                                                          
no message buffer overruns                                                 
no message buffer overruns                                                                 
no message buffer overruns                                       
jackdmp 1.9.12                                 
Copyright 2001-2005 Paul Davis and others.                                       
Copyright 2004-2016 Grame.                                                      
Copyright 2016-2017 Filipe Coelho.             
jackdmp comes with ABSOLUTELY NO WARRANTY      
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 10      
self-connect-mode is "Don't restrict self connect requests"                                                                                                                                                                                                                                                                               
Failed to connect to session bus for device reservation: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
To bypass device reservation via session bus, set JACK_NO_AUDIO_RESERVATION=1 prior to starting jackd.
Audio device hw:0 cannot be acquired...
Cannot initialize driver               
JackServer::Open failed with -1             
Failed to open server                         
Cannot connect to server socket err = No such file or directory                                   
Cannot connect to server request channel                                   
Cannot connect to server socket err = No such file or directory                            
Cannot connect to server request channel                         
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel     
Cannot connect to server socket err = No such file or directory                                   
Cannot connect to server request channel                                   
Cannot connect to server socket err = No such file or directory                            
Cannot connect to server request channel                         
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
fluidsynth: error: Failed to connect to Jack server.                            
Failed to create the audio driver              
FluidSynth version 1.1.9                       
Copyright (C) 2000-2018 Peter Hanappe and others.                             
Distributed under the LGPL license.          
SoundFont(R) is a registered trademark of E-mu Systems, Inc.

Additionally, running fluidsynth as root is a potential security risk.

There are also systemd user services, run as the user starting them. However, with them the alsa midi seqencer fails to initialize, as it requires the group audio:

ALSA lib seq_hw.c:466:(snd_seq_hw_open) open /dev/snd/seq failed: No such device
fluidsynth: error: Error opening ALSA sequencer
Failed to create the MIDI thread; no MIDI input
will be available. You can access the synthesizer
through the console.

In user services though, additional groups can not be set leading to the above problem.

There is the possibility to run a system service with user privileges though, using a templated unit.
I created something like

[Unit]
Description=FluidSynth Daemon for user %I
After=sound.target

[Service]
User=%I
SupplementaryGroup=audio
EnvironmentFile=/etc/conf.d/fluidsynth
ExecStart=/usr/bin/fluidsynth -is -a $AUDIO_DRIVER $OTHER_OPTS $SOUND_FONT

[Install]
WantedBy=multi-user.target

and it works!

I'd be happy, if you'd considered adding this file as a feature, as I think other distributions would benefit from this, too.

I think some more security features, that systemd offers can be added, but I have to work on some other things right now.
Would be great to get some feedback for this, though!

[derselbst]

Looks good, nice. I think it kinda addresses #66. Will try this for the openSUSE rpm package, on success will integrate it.

[dvzrv]

@derselbst damn, I think I made some false assumptions!

Although the templating file "works", the lvalue SupplementaryGroup is not correct. It should be SupplementaryGroups.

Also, it seems, that my system was crapping out because of a kernel update and no reboot, so now also the following systemd user service works (the MIDI issue seems to have been related to the new files, etc.):

[Unit]
Description=FluidSynth Daemon
Documentation=man:fluidsynth(1)
After=sound.target

[Service]
EnvironmentFile=/etc/conf.d/fluidsynth
EnvironmentFile=-%h/.config/fluidsynth
ExecStart=/usr/bin/fluidsynth -is -a $AUDIO_DRIVER $OTHER_OPTS $SOUND_FONT

[Install]
WantedBy=multi-user.target

You can easily test the above by placing it into ~/.config/systemd/user, running systemctl --user daemon-reload and then systemctl --user start fluidsynth (assuming you've setup either of the two configuration files!).

[dvzrv]

Note, the - prefixing the second EnvironmentFile, making it optional, but the system-wide a requirement.

[derselbst]

Ok. Did you intentionally remove SupplementaryGroups?

[dvzrv]

Yes. For user services that doesn't work.
SupplementaryGroups is only valid in system services (my previous post shows a user service)

So, there are two ways of going about it: A templated system service (from the initial post), or a user service (from the previous post).
I'd prefer the 2nd as that doesn't require root to start it.

However, only the first case can autostart by default (that only makes sense, if your audio system is up and running automatically as well).
The 2nd case can only autostart, if the the user's session state has been set to linger (loginctl enable-linger <username).

[derselbst]

aa3703b should implement the user service properly. Havent tested it yet. The idea is that a packager sets the FLUID_DAEMON_ENV_FILE cmake var in order to generate fluidsynth.service and fluidsynth.conf files.

cmake -DFLUID_DAEMON_ENV_FILE=/usr/lib/systemd/whatever/sysconfig.fluidsynth ..

The packager is responsible to properly install those files then, because their location varies too much between distributions and I dont think introducing even more CMAKE_INSTALL_DIR_* variables for this is a good idea.

Note that I've removed the $AUDIO_DRIVER var, as there is no guarantee that fluidsynth has been compiled to support this requested driver, because if not, it would just silently fail to start up. By default better let fluidsynth decide which driver to use, alternatively this ofc can be selected with the $OTHER_OPTS var, hoping the user knows what he does.

[dvzrv]

@derselbst looks good to me!
Looking forward to ship it! :)
Is there any ETA on a target release for this?

[derselbst]

Maybe next week if I find time this weekend.