Snapcast: snapclient could not open PID file

[slackline]

Hi,

Running snapclient on a Pi3 under ArchLinuxARM and have recently encountered this error...

Feb 15 10:02:45 alarmpi systemd[1]: Started Snapcast client.
Feb 15 10:02:44 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi kernel: audit: type=1130 audit(1581760964.973:108): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi kernel: audit: type=1131 audit(1581760964.973:109): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi kernel: audit: type=1130 audit(1581760964.993:110): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:44 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi snapclient[1167]: Exception: Could not open PID lock file "/var/run/snapclient/pid"
Feb 15 10:02:45 alarmpi snapclient[1167]: daemon terminated.
Feb 15 10:02:45 alarmpi systemd[1]: snapclient.service: Main process exited, code=exited, status=1/FAILURE
Feb 15 10:02:45 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'.
Feb 15 10:02:45 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Feb 15 10:02:45 alarmpi kernel: audit: type=1131 audit(1581760965.053:111): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Feb 15 10:02:45 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 3.
Feb 15 10:02:45 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 15 10:02:45 alarmpi systemd[1]: Stopped Snapcast client.

It gets to five tries then gives up.

There is no /var/run/snapclient directory within which to create the PID file, manually creating one doesn't resolve this.

Weirdly I can start snapclient at the command line ok, it creates /var/run/snapclient/pid no problem and uses the same /etc/default/snapclient configuration.

The systemd snapclient.service look like...

# cat /usr/lib/systemd/system/snapclient.service 
[Unit]
Description=Snapcast client
Documentation=man:snapclient(1)
Wants=avahi-daemon.service
After=network.target time-sync.target sound.target avahi-daemon.service

[Service]
EnvironmentFile=-/etc/default/snapclient
ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS
User=snapclient
Group=snapclient
# very noisy on stdout
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target

...and /etc/default/snapclient...

# cat /etc/default/snapclient
# defaults file for snapclient

# start snapclient automatically?
START_SNAPCLIENT=true

# Allowed options:
#   --help                          produce help message
#   -v, --version                   show version number
#   -h, --host arg                  server hostname or ip address
#   -p, --port arg (=1704)          server port
#   -l, --list                      list pcm devices
#   -s, --soundcard arg (=default)  index or name of the soundcard
#   -d, --daemon [=arg(=-3)]        daemonize, optional process priority [-20..19]
#   --user arg                      the user[:group] to run snapclient as when daemonized
#   --latency arg (=0)              latency of the soundcard
#   -i, --instance arg (=1)         instance id

USER_OPTS="--user snapclient:audio"

SNAPCLIENT_OPTS="-d -h 192.168.1.21 -p 1704"

I read here that creation of PID is solely down to snapclient and not systemd responsibility so am stumped as to what to do here.

If I create the /var/run/snapclient/ directory and set ownership to snapcast:audio it works ok...

 # mkdir /var/run/snapclient
mkdir: cannot create directory ‘/var/run/snapclient’: File exists
 # chown -R snapclient:audio /var/run/snapclient
 # systemctl start snapclient.service
 # systemctl status snapclient.service
● snapclient.service - Snapcast client
     Loaded: loaded (/usr/lib/systemd/system/snapclient.service; enabled; vendor preset: disabled)
     Active: inactive (dead) since Sat 2020-02-15 10:14:14 UTC; 3s ago
       Docs: man:snapclient(1)
    Process: 1274 ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS (code=exited, status=0/SUCCESS)
   Main PID: 1274 (code=exited, status=0/SUCCESS)

Feb 15 10:14:14 alarmpi systemd[1]: Started Snapcast client.
Feb 15 10:14:14 alarmpi snapclient[1275]: daemon started
Feb 15 10:14:14 alarmpi systemd[1]: snapclient.service: Succeeded.

Service runs fine on four other RaspberryPi ZeroW's running ArchLinuxARM. I'm using the AUR build but am still on 0.17.1 as I can't get 0.18.1-1 to build (see #548).

Any advice welcome.

Thanks.

[daverck]

same issue with raspbian buster on raspberry 3
(the directories /var/run/snapclient/ and /var/run/snapserver are deleted on reboot if I create them.)

[slackline]

I've successfully built and installed 0.18.1 but the problem of /var/run/snapserver not existing still persists.

I see on line 177 of snapclient.cpp the directory and pid are referenced but I'm wondering if this is something that systemd should handle on starting the service or not (link in my report above suggests its down to the programme though and I don't know enough to say know way).

[slackline]

I think I might have worked out what was causing this problem, but not why.

My Pi stopped outputting sound yesterday so I had recourse to check the software before moving onto troubleshooting the hardware. In doing so I found that I had the following in /etc/default/snapclient

SNAPCLIENT_OPTS="-d -h 192.168.1.21 -p 1704"

...but on checking my PiZero clients I had the following...

SNAPCLIENT_OPTS="-h 192.168.1.21"

Removing the -d flag seemed to do the trick (no harm in having the -p flag) and when snapclient is started by systemd the /var/run/snapclient/pid file is now created without any problem.

That a solution/work around that has worked for me, @daverck if you could see if this works for you too that would no doubt be useful.

I don't understand enough to say why having the option to start as a daemon in the default configuration prevents the file from being created.

[daverck]

Thank you @slackline

Removing -d helped.

I also had to change the owner/group of /var/lib/snapserver/snapserver.json to snapserver:snapserver

In /ect/default/snapclient I changed SNAPCLIENT_OPTS="--host localhost" to SNAPCLIENT_OPTS=""

which got me rid of this error

snapclient[2779]: Exception in Controller::worker(): connect: Connection refused

but I still haven't found the right config to use snapserver with mopidy-iris

N.B. using snapserver/snapclient version 18.1-1

[daverck]

ok finally I got it working :)

This is the settings that work for /etc/mopidy/mopidy.conf

[audio]
output = audioresample ! audioconvert ! audio/x-raw,rate=48000,channels=2,format=S16LE ! wavenc ! filesink location=/tmp/snapfifo

bad settings I tried :

output = audioresample ! audioconvert ! audio/x-raw, rate=48000, channels=2, format=S16LE ! wavenc ! filesink location=/tmp/snapfifo?name=default

output = alsasink

mixer = software

[slackline]

Just been browsing the Pull Requests and came across Create PIDfile before parent exits for systemd by stuart12 · Pull Request #275 · badaix/snapcast.

Whilst I've solved my problem by sorting out the configuration options I'm wondering if this is perhaps a wider fix?

[mogwa1]

Hi, I'm the maintainer for the archlinux package.

You shouldn't be passing the "-d" option to the client if you are running it through systemd. (This holds for any type of process, not only snapclient, unless you set the systemd type to "forking".)
The idea is that systemd can start up and track the snapclient process, including keeping track of the stdout and stderr.

If you pass on "-d" then it will look to systemd like the process started and immediately quit again because it will fork itself into another thread which systemd has no control over. Systemd will hence try to restart the process again (ending up in a loop).

The "-d" option is only useful if you start snapclient on the command line and you want it to fork itself into a separate process that will still continue if you close the terminal.

[slackline]

Thanks for the detailed explanation @mogwa1 appreciated. I'm still on the learning curve with systemd as I've stuck with OpenRC on my main Gentoo install and am learning systemd here and there running Arch Linux on my RaspberryPi/VPS. Explanations like this are very much appreciated, so again, thank you for taking the time to explain it.

[mogwa1]

@slackline: You're welcome. I just noticed that you had posted a similar comment on the AUR page a few months ago. I must have somehow missed that message.