Closed yattaro closed 1 year ago
Thank you. I assume by droping in teh openrc script into the folder where the slingbox_server.py is, the server will automatically run upon startingup or rebooting Pi. If so, wow. Thank you @yattaro
Thank you. I assume by droping in teh openrc script into the folder where the slingbox_server.py is, the server will automatically run upon startingup or rebooting Pi. If so, wow. Thank you @yattaro
Assuming you're using Gentoo or some other openrc-based distro, you place the openrc script in /etc/init.d, the server files in /home/slingbox just like on systemd, mark both the script and slingbox_server.py as executable, and run it like a normal service (IE rc-service sling
start). Otherwise, follow the README like normal.
You don't need to make the python script as executable. It's run by the python program. There no header in it to tell the shell what program to use to run it.
Also, you don't need the rc.d script use the sling.service file as documented in the readme. You'll need to edit it because your files are not in the same place that the configuration expects.
Adding one was part of this commit; the openrc script calls slingbox_server.py directly because that's how the supervisor daemon expects it.
Did you test this? How does the script know what python interpreter to use?
Yes, I tested this on my Gentoo machine. The shebang line #!/usr/bin/env python
in slingbox_sever.py tells it to find the Python executable in the PATH, as opposed to hardcoding the path to the executable, which is more portable. Effectively, command="${directory}/slingbox_server.py"
treats it like a shell script, with the Python interpreter being the shell here.
There is NO shebang line in the official version of the slingbox_server.py. So I don't know where you got it from but it will fail for everybody after an update.
The shebang was added in this PR, which was already merged a month ago though, and there have been quite a few commits since? I'm a bit confused as to where you're going with this, or how it will adversely affect existing setups when it doesn't apply to any platform that uses systemd.
Where I'm going with this. Is the location of the python executable is NOT in the same place on every Linux system and the executable isn't always call "python" in some cases it python3. That piece of code should never have been merged and I'm going to take it out.
On most modern systems, python
should be and is aliased to python3
because nobody should be using 2.7 anymore. If that is an issue though, just change the line to python3? In either case, /usr/bin/env is literally there to get the correct path to the executable from PATH without having to worry about knowing where it is on every system. Your systemd unit was also already pointing to /usr/bin/python before this commit and working just fine.
Using env to call the Python executable from $PATH is generally a safer bet for portability than hard-coding the path, so I modified
sling.service
accordingly. Also created a corresponding OpenRC script (sling_openrc
) tested to work on Gentoo. OpenRC users can drop this file in/etc/init.d/
and mark both it and/home/slingbox/slingbox_server.py
as executable to have an equivalent service.