如何让这个systemd脚本在ArchLinux上运行？

Question

I have a firewire device hooked into a machine running arch linux.

I got FFADO working, and after I execute ffado-dbus-server I can start using the firewire device with Jack and Pulseaudio (that convolution is entirely unrelated to my issue here)

I basically have to run 3 different steps each time I boot to get my sound working. I'm trying to get all of this magic to happen automatically at boot.

I read about /etc/rc.local but it seems that no such file exists on my arch linux install. I read about the boot process on arch linux and it seems that arch doesn't use rc.local and instead uses systemd

I went through the arch wiki page on systemd and tried to create a simple ffado-dbus.service unit file in /usr/lib/systemd/system

I started trying to use a unit type of dbus , then tried oneshot , and finally simple

No matter what I do the results are pretty much consistent. The service fails.

I also tried putting the service in usr/lib/systemd/user and tried running this as systemctl --user start but that also produced the same failure.

The simplest example of the unit file I have is this:

[Unit]
Description=FFADO DBus startup

[Service]
Type=simple
ExecStart=/usr/sbin/ffado-dbus-server

That produces the following status:

[pigdog@livingroom system]$ sudo systemctl status ffado-dbus -l
● ffado-dbus.service - FFADO DBus Service
   Loaded: loaded (/usr/lib/systemd/system/ffado-dbus.service; static; vendor preset: disabled)
   Active: failed (Result: core-dump) since Sun 2015-03-01 04:31:59 MST; 5s ago
  Process: 3934 ExecStart=/usr/bin/ffado-dbus-server (code=dumped, signal=ABRT)
 Main PID: 3934 (code=dumped, signal=ABRT)

Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: FFADO Control DBUS service
Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: Part of the FFADO project -- www.ffado.org
Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: Version: 2.2.1-Unversioned directory
Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: (C) 2008, Pieter Palmers
Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: This program comes with ABSOLUTELY NO WARRANTY.
Mar 01 04:31:59 livingroom ffado-dbus-server[3934]: -----------------------------------------------
Mar 01 04:31:59 livingroom systemd[1]: ffado-dbus.service: main process exited, code=dumped, status=6/ABRT
Mar 01 04:31:59 livingroom systemd[1]: Unit ffado-dbus.service entered failed state.
Mar 01 04:31:59 livingroom systemd[1]: ffado-dbus.service failed.
Mar 01 04:32:00 livingroom systemd-coredump[3944]: Process 3934 (ffado-dbus-serv) of user 0 dumped core.

There is some mysterious code 6/ABRTthat happens in the main process of ffado-dbus-server

I assume this is because the "environment" that systemd is running in doesn't contain processes or something that ffado needs to run. What I don't understand is how I determine what is missing, and then how do I provide this to the systemd environemnt.

Alternatively, I'd love to just make the systemd environment match the "pigdog" user environment from which I just executed the systemctl call. I thought that's what I'd be doing by moving the ffado-dbus.service file into /usr/lib/systemd/user and then calling systemctl like systemctl --user but this produces the same error.

I also tried adding the User=pigdog directive to the [Service] section of the unit file with no success.

I can run /usr/bin/ffado-dbus-server from bash while logged in as pigdog without issue. I get the following output when the script succeeds:

[pigdog@livingroom system]$ /usr/bin/ffado-dbus-server
-----------------------------------------------
FFADO Control DBUS service
Part of the FFADO project -- www.ffado.org
Version: 2.2.1-Unversioned directory
(C) 2008, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

1425209640984446:  (ffado-dbus-server.cpp)[ 270] main:  Discovering devices...
00973362057: Debug (devicemanager.cpp)[ 354] discover: Starting discovery...
00973405357: Debug (devicemanager.cpp)[ 616] discover: driver found for device 0
00973405880: Debug (devicemanager.cpp)[ 653] discover: discovery of node 0 on port 0 done...
00973405944: Debug (devicemanager.cpp)[ 661] discover: Discovery finished...
00973405980: Debug (devicemanager.cpp)[1258] showDeviceInfo: ===== Device Manager =====
00973406020: Debug (Element.cpp)[ 121] show: Element DeviceManager
00973406047: Debug (devicemanager.cpp)[1266] showDeviceInfo: --- IEEE1394 Service  0 ---
00973406085: Debug (devicemanager.cpp)[1276] showDeviceInfo: --- Device  0 ---
00973406113: Debug (devicemanager.cpp)[1279] showDeviceInfo: Clock sync sources:
00973406165: Debug (devicemanager.cpp)[1288] showDeviceInfo:  Type: Internal          , Id:  0, Valid: 1, Active: 1, Locked 1, Slipping: 0, Description: Internal sync
00973406199: Debug (devicemanager.cpp)[1288] showDeviceInfo:  Type: ADAT              , Id:  1, Valid: 1, Active: 1, Locked 1, Slipping: 0, Description: ADAT optical
00973406237: Debug (devicemanager.cpp)[1288] showDeviceInfo:  Type: SPDIF             , Id:  2, Valid: 1, Active: 1, Locked 1, Slipping: 0, Description: SPDIF/Toslink
00973406266: Debug (devicemanager.cpp)[1288] showDeviceInfo:  Type: Erratic type      , Id:  3, Valid: 0, Active: 0, Locked 0, Slipping: 0, Description: SMPTE
00973406303: Debug (devicemanager.cpp)[1288] showDeviceInfo:  Type: WordClock         , Id:  4, Valid: 1, Active: 1, Locked 1, Slipping: 0, Description: Wordclock
00973409421:  (ffado-dbus-server.cpp)[ 329] main: DBUS service running
00973409433:  (ffado-dbus-server.cpp)[ 330] main: press ctrl-c to stop it & exit
00973409436: Debug (ffado-dbus-server.cpp)[ 333] main: dispatching...

Answer 1

When you run a startup script from a shell prompt, and it works, but the startup script fails when launched from systemd -- as is apparently in your case -- ninety nine times out of a hundred the problem is the environment.

I would investigate it as a first order of business -- whether the ffado package sets up some default shell environment variables that are needed by its startup script.

If so, then this becomes a simple matter of setting up the same environment variables before executing the startup script, in the systemd unit file.