I have a PC that transmits log data over a TCP/IP socket to a Raspberry Pi. I have written a python server program that runs on the Pi, so that when certain keywords are encountered, it has to play the corresponding audio track - this is a gist of the problem I'm currently working on.
Now, I want this server program to run as soon as the Raspberry Pi boots up, and so I wrote a systemd service to enable that. Assuming my server code is named as server.py, my service file looks as follows:
[Unit]
Description=Python Server
[Service]
# Command to execute when the service is started
ExecStart=/usr/bin/python3 -u /usr/bin/server.py
[Install]
WantedBy=multi-user.target
I make this server program executable, and I don't face any issues to start and enable the service (verified by rebooting the Pi as well). Now, taking a step back, I play the audio track on the python server program using the following lines (a little snippet):
import subprocess
subprocess.run(["cvlc", "~/Downloads/doors.wav"])
No errors here, all good. But when the service that runs the server program is started, when the specific keyword is encountered, the audio track does not play - it shows an error:
: [00005565470df480] vlcpulse audio output error: PulseAudio server connection failure: Connection refused
: [0000556547157310] dbus interface error: Failed to connect to the D-Bus session daemon: Unable to autolaunch a dbus-daemon without a $D
: [0000556547157310] main interface error: no suitable interface module
: [000055654700c570] main libvlc error: interface "dbus,none" initialization failed
: [0000556547101460] main interface error: no suitable interface module
: [000055654700c570] main libvlc error: interface "globalhotkeys,none" initialization failed
: [0000556547101460] dummy interface: using the dummy interface module...
: [00007f5f98c0b610] idummy demux: command `quit'
This same error shown above occurs when I try to play the audio from the command line with sudo, that is:
cvlc ~/Downloads/doors.wav
which led me to believe that if the service is enabled, then the whole python program corresponding to the service is run with sudo privileges automatically, even if I don't intend that to happen. I did a little bit of digging, but based on what I understand, to run the service, sudo privilege is necessary. I was not able to find a solution to run vlc with sudo, although I understand that ideally sudo privileges should not be given to something such as vlc. Is there a way around this?
This is happening because the PulseAudio server runs under your user, not as root. The service you are starting runs as root and tries to connect to root's PulseAudio server.
You can run specify which user/group to run the service as under the [Service] section with the User and Group directives.
You can also run the service as your user like this:
$ systemctl start --user <service>.service
Related
I have a server built on bottle that works great when launched from userland. The server appears on port 8088 and appears to be communicating to the outside world, but when I contact the app all I get is the very informative "Critical error while processing request:schema" which is the url of the app.
My systemd file is below:
[Unit]
Description=Survey Service
After=multi-user.target
Conflicts=getty#tty1.service
[Service]
User=ubuntu
Type=simple
Working-directory=/home/ubuntu/survey
ExecStart=/usr/bin/python3 /home/ubuntu/survey/server.py
[Install]
WantedBy=multi-user.target
I've found several articles related to the informative error message, but none related with systemd. As I said, the app runs perfectly when launched as user ubuntu in the project directory with the very simple command "python3 server.py" but seems to be missing... something when systemd tries to launch it.
Systemd reports the process is running and, as I said, I'm able to connect to the app... it just fails in an orderly fashion with this message, and I'm lost as to why. I suspect a permissions problem, but doesn't "user" and "Working-directory" take care of that? All files used by the app are in that directory or directories below it.
Apparently doing it the old fashion way works: set systemd to run a bash script as such:
cat /home/ubuntu/survey/server.sh
#!/bin/bash
cd /home/ubuntu/survey/
python3 server.py
Works just great. So my question now becomes one about systemd: what is the point of "Working-directory" if it does not actually set to that working directory?
I created a small go program that uses these go bindings to record some commands from the default microphone and act accordingly. It works fine as a standalone binary(both as normal user and root user) but when I tried to convert it into a systemd unit the Capture function in the go bindings failed with error saying connection refused.
The program is failing to capture the microphone input when running as a systemd service. The following is the unit file which is pretty much copy-pasted from here.
[Unit]
Description=Commander service providing voice commands
[Service]
ExecStart=/path/to/binary/binary.sh
[Install]
WantedBy=multi-user.target
binary.sh is a simple shell script that for providing environment variables to the go binary. The script is below
#!/bin/bash
cd /path/to/binary
env LD_LIBRARY_PATH=/usr/local/lib ./binary > stdout 2> stderr
The LD_LIBRARY_PATH is needed for pocketsphinx shared libraries which is being used for recognizing commands from audio.
I think something is wrong with the unit file but I don't know what it is. The whole project can be found here.
Any insight would be helpful. Thanks.
pulseaudio is a daemon which probably has yet to get launched ... update your binary.sh with a
sleep 10
echo about to determine whether pulseaudio is up and running
pulseaudio --check
echo if pulseaudio is running above check silently returns
prior to launching your golang binary
It is required to set XDG_RUNTIME_DIR environmental variable to directory /run/user/<USER_ID>, e.g.
[Service]
Environment="XDG_RUNTIME_DIR=/run/user/1001"
ExecStart=/path/to/binary/binary.sh
I have to run my application as service in ubuntu 16.04. I am using systemd to make it run as service during bootup time. My application has to connect to both session dbus and system dbus.
connecting to system dbus is successful. But connecting to session dbus is failing.
I tried to run my application as service using "systemctl start Myapplication", this time also it is not connecting to session bus.
But if I run my application from terminal by "./Myapplication" , it is successfully connecting to both session and and system dbus.
can anyone help me with this?
The below code is my .service file content.
[Unit]
Description=node-health-monitor to observe system health
[Service]
Type=notify
ExecStart=/home/deepan/deepan/Myapplication
[Install]
WantedBy=graphical.target
Iam using GDBUS.
Set it up as user-service (so it can be run as systemctl --user start Myapplication).
Or keep using it as a system-wide service, but somehow switch the user in Myapplication when connecting to the session bus.
What I think causes problems:
The Myapplication is run as root user when doing systemctl start Myapplication.
So when it tries to connect to the session bus, it's trying to connect to the session of the root user.
I am having a problem with a small application I developed on the BBB running Debian Image 2017-03-19.
I connected a barcode scanner to the usb port and a 2x16 LCD display to the GPIO controlled by BBBioLib.
I developed an application in C to read a barcode label apply to a race tyre, which find a match on an SQLite table and show the racer name on the display.
Application work great but since the all assembly must work stand alone I need to run the program automatically at boot.
I follow all the instruction on creating a bash program and service but I am getting a strange behaviour.
The display after the welcome message hang up and never change but the application work correctly because all the printf to the consolle get logged correctly and once I exit the application I can check them on the log of the service.
If I restart the service manually everything work fine.
This is the bash script
#!/bin/bash
/root/read_barcode
This is the service code
[Unit]
Description=Barcode reader launch
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/usr/bin/barcode.sh
[Install]
WantedBy=multi-user.target
Does anyone can help on solving this problem.
Thanks
Carlo
Run a .service file with sudo systemctl enable YourService.service at this location.
/etc/systemd/system/
Use the enable option for systemd .service files to make your source work on boot or a reboot.
I'm trying to create a service that will trigger every time a raspberry pi boots. Currently the service runs a really simple script that sends a POST request to a web service endpoint I control. I can trigger said script manually and that part all works perfectly.
I'm struggling with the next step which is to get that script to run after the pi has finished booting. I also need to be able to get it to run without a user logging in.
CURL Script (algiers-startup.local)
#! /bin/bash
echo "Attempting CURL Request"
curl --data "param1=value1¶m2=value2" http://10.68.159.28:3000/device
Systemd Service
[Unit]
Description=Algiers RaspberryPi Startup
After=network.target
Before=getty#tty1.service
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/algiers-startup.local
TimeoutSec=30
StandardOutput=tty
RemainAfterExit=no
[Install]
WantedBy=multi-user.target
I see no errors or outputs in the console, no hint that anything has happened at all.
I’ll assume your machine is already set up with Systemd. It’s controlled primarily through the systemctl command. I alias it as such since it’s awful to type all the time:
alias sc=systemctl
alias ssc='sudo systemctl'
You just need to “enable” your service to have it run at boot:
sc enable algiers-startup
I’m not sure what distro you’re using, but on Arch and CentOS, you’ll want algiers-startup to live down in /usr/lib/systemd/system/.
You can test your service with sc start algiers-start. journalctl can show you what’s happening.