Cannot connect to MPD from systemd script

[Zavulon]

Had a similar setup working before without problems. mpd is started by systemd, script also started by systemd. script uses systemd to control mpd. All mpc calls get result

$this->bbcode_second_pass_code('', 'mpd error: Connection refused')

mpd is bound to localhost 6600, script sets MPD_HOST and MPD_PORT. Networks are up and running before the script calls mpc.
Once the system is up I can SSH in and use su to root then call mpc from the command line without problem.

The actual usage of mpc/mpd will be from a Python program. The system is a Raspberry Pi B+. Network IP on eth0 is setup by netctl for a fixed IP address (no wifi). The Python program must run as root to use external USB hardware via pyserial.

output of uname -a

$this->bbcode_second_pass_code('', 'Linux alarmpi 4.1.15-5-ARCH #1 Wed Jan 20 14:17:59 MST 2016 armv6l GNU/Linux')

/etc/mpd.conf

$this->bbcode_second_pass_code('', 'pid_file "/run/mpd/mpd.pid"
db_file "/var/lib/mpd/mpd.db"
state_file "/var/lib/mpd/mpdstate"
playlist_directory "/mnt/music/playlists"
music_directory "/mnt/music"
log_file "/var/log/mpd.log"
#bind_to_address "::"
#bind_to_address "192.168.1.75"
bind_to_address "localhost"
port "6600"
log_level "verbose"
#user "mpd"

audio_output {
type "alsa"
name "default"
device "plughw:0,0"
mixer_type "software"
}
')
systemd service in /etc/systemd/system/default-target-wants

$this->bbcode_second_pass_code('', '[Unit]
Description=Music Player Daemon
After=network.target sound.target

[Service]
ExecStart=/usr/bin/mpd --no-daemon
# allow MPD to use real-time priority 50
#LimitRTPRIO=50
#LimitRTTIME=infinity

[Install]
WantedBy=default.target')

Custom service in /etc/systemd/system/default-target-wants

$this->bbcode_second_pass_code('', '[Unit]
Description= IbusMp3 Service
Requires=network-online.target sound.target mpd.service
After=network.target network-online.target sound.target mpd.service
Wants=network-online.target sound.target mpd.service

[Service]
Type=idle
#ExecStart=/usr/bin/python2 /opt/ibusmp4/ibusmp4.py
ExecStart=/home/alarm/start.s

[Install]
WantedBy=multi-user.target

')/home/alarm/start.s

$this->bbcode_second_pass_code('', '#!/usr/bin/bash
export MPD_HOST="localhost"
export MPD_PORT="6600"
>/home/alarm/start.log
ifconfig >> /home/alarm/start.log
echo `whoami` >> /home/alarm/start.log

mpc play 1>>/home/alarm/start.log 2>&1
mpc play 1>>/home/alarm/start.log 2>&1
#sleep 5
mpc play 1>>/home/alarm/start.log 2>&1
exit $?
')
start.log after boot:

$this->bbcode_second_pass_code('', 'eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.75 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:51:f4:23 txqueuelen 1000 (Ethernet)
RX packets 3 bytes 702 (702.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8 bytes 1716 (1.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 162 bytes 12778 (12.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 162 bytes 12778 (12.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

root
mpd error: Connection refused
mpd error: Connection refused
mpd error: Connection refused
')
start.log after running start.s from a logged in session via ssh

$this->bbcode_second_pass_code('', 'eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.75 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:51:f4:23 txqueuelen 1000 (Ethernet)
RX packets 544 bytes 48102 (46.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 997 bytes 90104 (87.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 382 bytes 32956 (32.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 382 bytes 32956 (32.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

root
Kiss - Lick It Up
[playing] #395/1871 0:07/3:52 (3%)
volume:100% repeat: off random: on single: off consume: off
Kiss - Lick It Up
[playing] #395/1871 0:07/3:52 (3%)
volume:100% repeat: off random: on single: off consume: off
Kiss - Lick It Up
[playing] #395/1871 0:07/3:52 (3%)
volume:100% repeat: off random: on single: off consume: off
')
On the boot failure nothing is logged by MPD for the failed connection attempts ('mpd error: Connection refused' reported by mpc) - even with logging_level for MPD set to 'verbose'.

I've tried everything I could find online - but am thinking that this is networking issue, possibly due to ipV6 - to which end I've done my best to disable ipv6 by using
$this->bbcode_second_pass_code('', '
ipv6.disable_ipv6=1')

in my cmdline.txt

I am now out of ideas, any suggestions on debugging the issue or resolving gladly received.

[wobble]

I imagine the mpd service might take some time before it starts accepting connections. Have you tried what happens if you insert a sleep command before the first invocation of mpc in your script?

[Zavulon]

Thanks Wobble. I had previously tried a 2 second delay without success. But determined to give a good try to any offered suggestion I thought 'why not' and set a 20 second delay: it worked. So did a chop on the delay and found 5 seconds to be sufficient - that's a long time to be waiting.

With that fixed I then re-enabled the python program in start.s and gave it a go .

Seems that with everything connected that mpd has trouble finding the hardware audio device (a phat dac from pimoroni). The only different hardware is a USB serial interface connected to the Pi. This is referred to as ttyUSB0. Could mpd or alsa be confusing the serial interface and the phat dac?

Is there a better (more accurate way) of referencing the phat dac in the mpd config file than the snippet below?

$this->bbcode_second_pass_code('', 'audio_output {
type "alsa"
name "default"
device "plughw:0,0"
mixer_type "software"
}')

[WarheadsSE]

Use `journalctl -b -l` to read the whole logs for one boot, and check the timings of the two services starting. This should show you if you are hitting a race condition. It is also possible that the mpd is not _yet_ ready to accept the connections immediately when systemd thinks it is started.