Systemd unit file not working on Raspberry Pi

[tomsimmons78]

I have in completed all the steps to get this working, and when launched from the command line it does beautifully. If I copy the .service from from within the Debian folder to /etc/systemd/system, perford the systemctl daemon-reload, enable and start the service, the client can see and use the rendered.

However if I restart the Pi, check the service it is reported as active and ready, but the client can't see it. If I try and stop the service the stop-sigterm times out, but when that finally happens, if I then restart the service it is instantly available and works from the client.

Why?

Aside from the issue stopping it I can find no sign of an error.

[hzeller]

Can you try if adding the following in the top [Unit] section helps ?

After=network-online.target
Requires=network-online.target

[tomsimmons78]

@hzeller

Thanks for getting back to me.

With these changes, if I follow correctly, the .service file reads...

[Unit]
Description=gmrender-resurrect service
After=network.target sound.target network-online.target
Requires=network-online.target

[Service]
Environment="UPNP_DEVICE_NAME=Covehithe"
ExecStartPre=/bin/sh -c "/bin/systemctl set-environment UPNP_UUID=`ip link show | awk '/ether/ {print \"salt:)-\" $2}' | head -1 | md5sum | awk '{print $1}'`"

ExecStart=/usr/local/bin/gmediarender -f "$UPNP_DEVICE_NAME" -u "$UPNP_UUID" \
                                      --gstout-audiosink=alsasink --gstout-audiodevice=sysdefault \
                                      --logfile=/tmp/gmediarenderer.log --gstout-initial-volume-db=-10
Restart=always

[Install]
WantedBy=multi-user.target

I'm not a genius when it comes to LInux, I made the change, did a further daemon-reload, then a reenable for the service, a reboot however, the client is still not visible, and stopping still causes the error.

Tom

[mill1000]

For what it's worth, here's the service I've been using for a few years on my Raspberry Pi 3B

[Unit]
Description=GMediaRender
After=syslog.service network.target

[Service]
ExecStart=/usr/local/bin/gmediarender -f %H --mime-filter audio --gstout-buffer-duration=0 --uuid %m_0
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=GMediaRender
User=pi
Group=audio

[Install]
WantedBy=multi-user.target

More version info

Linux StereoBerry 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

[tomsimmons78]

@mill1000

Doesn't seem to help, still doesn't appear until stopped, which takes an age, then restarted

Tom

[mill1000]

Check this comment out as well: #129 (comment)

[coldtobi]

direct after the boot, what does systemctl status gmrender-resurrect say?
Any hints in journalctl -b -u gmrender-resurrect ?

[tomsimmons78]

@hzeller

direct after the boot, what does systemctl status gmrender-resurrect say? Any hints in journalctl -b -u gmrender-resurrect ?

Systemctl Status

Journalctl

Noting visible in the client.

Systemctl stop takes a while, resulting in (journalctl as you'd expect contains the same)

Systemctl start, succeeds and the client finds it.

[tomsimmons78]

@mill1000

For what it's worth, here's the service I've been using for a few years on my Raspberry Pi 3B

[Unit]
Description=GMediaRender
After=syslog.service network.target

[Service]
ExecStart=/usr/local/bin/gmediarender -f %H --mime-filter audio --gstout-buffer-duration=0 --uuid %m_0
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=GMediaRender
User=pi
Group=audio

[Install]
WantedBy=multi-user.target

More version info

Linux StereoBerry 5.10.63-v7+ #1496 SMP Wed Dec 1 15:58:11 GMT 2021 armv7l GNU/Linux
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

The main difference was the user and group, adding these made no difference

[tomsimmons78]

@mill1000

Check this comment out as well: #129 (comment)

A lot of this seems to date to the init.d stuff, the main point I tried from it was the pre exec with a delay of 10, sadly, still no difference.

[mill1000]

Anything of note in your logfile? The one at /tmp/gmediarenderer.log

What control point/client are you using?

[tomsimmons78]

@mill1000

Sadly not, nothing error or issue looking in there at all.

I'm using HiFi Cast on Android as the control point/client

[mill1000]

What client/control point are you using?

[tomsimmons78]

What client/control point are you using?

@mill1000

HiFi Cast on Android

[mill1000]

Huh. That's what I use. Never had this issue.

What version of libpupnp did you build against?

[tomsimmons78]

@mill1000

How would I check this?

[hzeller]

if you call

ldd $(command -v gmediarender)

You get an output which libraries are linked.

[hzeller]

Can you post the output of your /tmp/gmediarenderer.log ?

[tomsimmons78]

@hzeller

I can easily provide this, however I guess to ease your job it would be better if I cleared it, performed a restart, then stopped it, started the service manually and played something?

[hzeller]

So the important part is to see what (not) happens when the Pi reboots and it then doesn't show up. It could be an issue with the network not initialized or something.

We look for something like this in the logfile

Registered IP=a.b.c.d port=yyyyy

... followed by some logs which ultimately should show 'Ready for rendering'.

So since you experience the issue just after reboot (and not a regular restart of the service), the might be something happening there, so looking at that log generated right after boot would be helpful.

[tomsimmons78]

@hzeller

You won't believe it....

I deleted the log, rebooted and the bloody thing is working fine!

I therefore removed the pre exec sleep for 10 added as a result of the post linked to by @mill1000. I then deleted and rebooted again and and it once against stopped working. I have attached the log from when it fails.

gmediarenderer.log

So yes, I concur, it is trying to start before something is ready.

[hzeller]

so the logfile shows that it indeed hat issues initially (possibly network not ready), but then did the retry-loop and eventually was able to and ready and listened on the port.

Is the IP address you see 192.168.0.9 the one you expect the Pi to be listening on ? Is it always the same ?
Could it be that your router assigns different IP addresses via DHCP on every reboot of the Pi ? It might be useful to fix the same IP address for that Pi (most routers allow to statically assign an IP address for a particular hardware address). That way, your client application is not surprised when it sees the same renderer show up under a different IP address.

Do you connect via Wifi and ethernet ? Then the Pi gets two IP addresses via DHCP and this might also create trouble.

[tomsimmons78]

@hzeller

Only WiFi is used, and the IP is statically assigned from the router. The IP is the .0.9