DietPi-Software | GMRender chooses wrong IP address to advertise/bind

[WilburWalsh]

Creating a bug report/issue

Required Information

• DietPi version | 6.22 (dev)
• Distro version | stretch
• Kernel version | Linux pi1 4.14.98+ Request | RT Kernel option #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux
• SBC device | RPi B (armv6l)

Additional Information (if applicable)

• Software title | Gmediarender
• Was the software title installed freshly or updated/migrated? Freshly installed
• Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

1. install gmediarender on a system with multiple interfaces (e.g. OpenVPN server)
2. reboot and check running service

Expected behaviour

• gmediarender should use Wifi or Ethernet IP to advertize/bind service

Actual behaviour

• if multiple interfaces / IP addresses are available, gmediarender uses any of those, not necessarily the one it should (the one we need)

Extra details

Apparently gmediarender requires a specific IP address to use for libupnp (see here) If multiple addresses of the host are available, it is not specified which one is used.
I have an OpenVPN server running as well, and it chose its IP address instead of the "regular" Wifi IP address. The IP address to be used can be forced by the -I option when starting Gmediarender.

So in my opinion, there are a number of ways to deal with this, not sure which one would be the most suitable for Dietpi.

1. Leave it as it is, because the scenario of running OpenVPN, Wifi Hotspot or something similar on the same host as an "audio device" is a rather theoretical and uncommon setup. In this case, maybe a hint on the Software title page at Dietpi forum would be nice.
2. Use the IP address from /Dietpi/dietpi/.network and the -I flag when creating the gmrender.service file. Downside: If the IP address is dynamic/DHCP, this may not work.
3. Wait until network is up and start gmediarender with the freshly obtained IP address. Might take some more effort to implement.

If you'd like, I would try to get option 3 running and submit a PR, if I get it to work.

[MichaIng]

@WilburWalsh
Many thanks for reporting and as well fixing with PR 👍: https://github.com/Fourdee/DietPi/pull/2580

I will so some minor tweaks an merge.

[WilburWalsh]

Hi @MichaIng ,
not sure, if this is the right place, but as the PR is already merged...

After updating my RPi 1B to the new Beta release, I checked the output of journalctl for errors and problems and found the following

Mär 13 20:02:52 pi1 systemd[1]: [/etc/systemd/system/gmrender.service:8] Executable path is not absolute, ignoring: !/usr/bin/touch /var/log/gmrender.log
Mär 13 20:02:52 pi1 systemd[1]: [/etc/systemd/system/gmrender.service:9] Executable path is not absolute, ignoring: !/bin/chown gmrender:dietpi /var/log/gmrender.log

Obviously the ! Prefix is not supported anymore in the latest systemd version for Debian stretch 🤔
I checked the gmrender.service file with systemd-analyze on my Pi 3 B+ running Dietpi 6.21 and it also complains about it. Changing the prefix to + solves the problem. Not sure, why it is a problem, as the online manual for the latest version of systemd still shows the ! prefix as valid option. Very strange.

[MichaIng]

@WilburWalsh
Good find!

Perhaps ! is not yet supported by the systemd version that is shipped with Stretch. So yeah we need to change that to +. I will send the commit: 85baeec

[WilburWalsh]

But I'm pretty sure it did work back when we discussed the original changes to the service file. I would like to revert my system back to a state that contains the up-to-date versions of all packages from like 3 or 4 weeks ago. Unfortunately I haven't found a way to do this yet...

[MichaIng]

Okay I will also run some tests on Jessie, Stretch and Buster to compare. Although your error message seems very clear.
€: Verified ! works on Debian Buster but not on Stretch. So it's about the systemd version which is not current enough. And the docs are always about the most current systemd version.

• No big issue: ! provides a bid less permissions than +, sufficient for the task, but for this trivial well known command in practice it really doesn't matter.

[WilburWalsh]

The thing is I am still absolutely sure it did work before. Like I wrote here: #2580 (comment)
But I will probably never find out what happened ^^

[MichaIng]

@WilburWalsh
I guess you didn't check the systemd log that time since it as well does not lead to any failure and is only handled as warning by systemd. The log dir creation/chown is not required (usually) since it is pre-created automatically on install, so redoing this via systemd service ExecStartPre is only a failsafe thing, in case of accidental deletion or an issue with RAMlog and such.