Arch Linux User Repository

Source sha256sums was not updated..

==> Verification of source files with sha256sums...
snapcast-0.22.0.tar.gz ... ERROR
snapcast.sysusers ... Durchgelaufen
snapcast.tmpfiles ... Durchgelaufen
snapcast.install ... Durchgelaufen

@m040601 : Actually the doc folder in the package tarball is (primarily) meant for the github online documentation. These are md files that are linked through from the main README.md in the toplevel directory. But I can see some value in adding them to the package nevertheless. I've added them in 0.20.0-2.

Please include the content that this package's "docs" folder provides. It should be installed under '/usr/share/doc/snapcast' It has important information, that is not on the man pages. It is also included in the archive you're pulling from, https://github.com/badaix/snapcast/archive/v${pkgver}.tar.gz

@mogwai : Thanks for taking the time to help me out.

I do still have /etc/default/snapclient and it reads...

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"

Which I seem to have edited in the past since the IP address is that of the system so its unchanged.

It still fails though...

systemctl restart snapclient systemctl status snapclient ● snapclient.service - Snapcast client Loaded: loaded (/usr/lib/systemd/system/snapclient.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2019-12-28 06:40:23 UTC; 5s ago Docs: man:snapclient(1) Process: 11700 ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS (code=exited, status=1/FAILURE) Main PID: 11700 (code=exited, status=1/FAILURE)

Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. Dec 28 06:40:23 alarmpi systemd[1]: Stopped Snapcast client. Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 28 06:40:23 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 28 06:40:23 alarmpi systemd[1]: Failed to start Snapcast client.

journalctl reports that the problem is because it can not create the required PID file

journalctl -g snapclient Dec 28 06:40:21 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h> Dec 28 06:40:21 alarmpi kernel: audit: type=1130 audit(1577515221.819:1262): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe>Dec 28 06:40:21 alarmpi snapclient[11694]: Exception: Could not open PID lock file "/var/run/snapclient/pid" Dec 28 06:40:21 alarmpi systemd[1]: snapclient.service: Main process exited, code=exited, status=1/FAILURE Dec 28 06:40:21 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 28 06:40:21 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho>Dec 28 06:40:22 alarmpi kernel: audit: type=1131 audit(1577515221.959:1263): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe> Dec 28 06:40:22 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 1.

The directory /var/run/snapclient existed since I created it the other day when trying to troubleshoot this, but I didn't set the ownership to that of the snapclient user. Having now done so snapclient starts and runs fine. No idea why the directory disappeared though.

Thanks again for your time and for maintaining the package.

@slackline: There is only a file called /etc/snapserver.conf; there is no /etc/snapclient.conf. The configuration for the client (started through systemd) should still be put into /etc/default/snapclient, just as before with version 0.15. I think the idea is that mainly the server is run through systemd as a daemon. Usually the client is run as a regular user unless it's a headless system. So, could you try your old 0.15 setup for the client with 0.17.1 again? It should simply work as-is.

Hi,

Just upgraded from 0.15.0 to 0.17.1 and I can't seem to get snapclient working.

I've created /etc/snapclient.conf and set SNAPCLIENT_OPTS there...

cat /etc/snapclient.conf

SNAPCLIENT_USER="--user snapclient:audio"

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

...as these are what is required when initialising with systemctl

alarmpi etc # 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

But when I try starting I get...

systemctl restart snapclient.service

systemctl status snapclient.service

● snapclient.service - Snapcast client Loaded: loaded (/usr/lib/systemd/system/snapclient.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2019-12-25 13:44:18 UTC; 1min 22s ago Docs: man:snapclient(1) Process: 4135 ExecStart=/usr/bin/snapclient $SNAPCLIENT_OPTS (code=exited, status=1/FAILURE) Main PID: 4135 (code=exited, status=1/FAILURE)

Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. Dec 25 13:44:18 alarmpi systemd[1]: Stopped Snapcast client. Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 25 13:44:18 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. Dec 25 13:44:18 alarmpi systemd[1]: Failed to start Snapcast client.

And sure enough its not started...

-- The job identifier is 2750. Dec 25 13:49:32 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h Dec 25 13:49:33 alarmpi snapclient[4169]: Exception: Could not open PID lock file "/var/run/snapclient/pid" Dec 25 13:49:33 alarmpi snapclient[4169]: daemon terminated. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Main process exited, code=exited, status=1/FAILURE -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- An ExecStart= process belonging to unit snapclient.service has exited. -- -- The process' exit code is 'exited' and its exit status is 1. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit snapclient.service has entered the 'failed' state with result 'exit-code'. Dec 25 13:49:33 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Scheduled restart job, restart counter is at 5. -- Subject: Automatic restarting of a unit has been scheduled -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Automatic restarting of the unit snapclient.service has been scheduled, as the result for -- the configured Restart= setting for the unit. Dec 25 13:49:33 alarmpi systemd[1]: Stopped Snapcast client. -- Subject: A stop job for unit snapclient.service has finished -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A stop job for unit snapclient.service has finished. -- -- The job identifier is 2819 and the job result is done. Dec 25 13:49:33 alarmpi audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" h Dec 25 13:49:33 alarmpi audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=snapclient comm="systemd" exe="/usr/lib/systemd/systemd" ho Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Start request repeated too quickly. Dec 25 13:49:33 alarmpi systemd[1]: snapclient.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The unit snapclient.service has entered the 'failed' state with result 'exit-code'. Dec 25 13:49:33 alarmpi systemd[1]: Failed to start Snapcast client. -- Subject: A start job for unit snapclient.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- A start job for unit snapclient.service has finished with a failure. -- -- The job identifier is 2819 and the job result is failed.

There are mentiones of a missing /var/run/snapclient/pid file not being accessible and there was no such directory so I created it but it still failed (see last output above for job 2819).

Any pointers on what I should be doing are welcome.

Since some time I have troubles connecting mopidy to snapserver. The internal GStreamer pipeline always terminates immediately with a permission denied error. I just found out that there is a new kernel feature that prevents accessing fifos owned by different users, which is causing this issue: https://unix.stackexchange.com/questions/503111/group-permissions-for-root-not-working-in-tmp

Problem is fixed now, still don't know what exactly the problem was. Thanks for fixing

I have changed the source path for sysusers and tmpfiles, even though I was not able to reproduce the problem. Please check if this solves it.

I agree with @crystaly, paths should be fixed.