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.
Related
I would like to start a GUI application when the session starts
It is a CM4 with a 5 inch touch screen, the purpose is to launch an application when Ubuntu starts.
Via a terminal, when I start it (./main) it works without problem
I tried via startup applications but it doesn't work, I don't know why
I tried via systemd but it doesn't seem to work for graphical applications
[Unit]
After=network.service
[Service]
ExecStart=/home/ubuntu/path/main
[Install]
WantedBy=multi-user.target
I tried via /etc/rc5.d but that doesn't work either
What am I doing wrong?
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 am currently working on Beaglebone Black (pre-installed Debian Linux Wheezy, kernel 3.8.13). I have written a simple service file which supposedly executes a pre-built binary "main.bin" file of a client program whenever the board boots up. The service file can be located as /etc/systemd/system/start_application.service
Service file contains these lines
[Unit]
Description=Client_Service
After=syslog.target network.target
[Service]
Type=simple
ExecStart=/home/debian/Desktop/start_application
[Install]
WantedBy=multi-user.target
If I start the service and try to check the CPU usage (I have systemd installed and perfectly working)
root#beaglebone:~# systemctl start start_application.service
root#beaglebone:~# top
I tried multiple times, observed for hours to confirm and found that, the program started (Please see the main.bin) using systemctl consumes huge CPU%. Here is the screenshot of the result
Instead of using the system service facility, if I execute the same program manually from command-line
root#beaglebone:~# cd /home/debian/Desktop/
root#beaglebone:/home/debian/Desktop# ./start_application
I found that it runs normally and consumes normal amount of CPU cycles. Here is the screenshot of the result.
Where am I making the mistake in the system service script ?
I'm trying to get a nodejs server to run on startup, so I created the following systemd unit file:
[Unit]
Description=TI SensorTag Communicator
After=network.target
[Service]
ExecStart=/usr/bin/node /home/pi/sensortag-comm/sensortag.js
User=root
[Install]
WantedBy=multi-user.target
I'm not sure what I'm doing wrong here. It seems to fail before the nodejs script even starts, as no logging occurs. My script is dependent on mysql 5.5 (I think this is where I'm running into an issue). Any insight, or even a different solution would be appreciated.
Also, it runs fine once I'm logged into the system.
Update
The service is enabled, and is logging through journalctl. I'll update with the results on 7/11/16.
Not sure why it didn't work the first time, but upon checking journalctl the issue was 100% that MySQL hadn't started. I once again changed it to After=MySQL.service and it worked perfectly!
If there is no mention of the service at all in the output of journalctl that could indicate that the service was not enabled to start at boot.
Make you run systemctl enable my-unit-name before your next boot test.
Also, since you depend on MySQL being up and running, you should declare that with something like: After=mysql.service. The exact service name may depend on your Linux distribution, which you didn't state.
Adding User=root adds nothing, as system units would be run by root by default anyway.
When you said "it fails", you didn't specify whether it was failing at boot time, or with a test run by systemctl start my-unit-name.
After attempting to start a service, there should be logging if you run journalctl -u my-unit.name.service.
You might also consider adding StandardOutput=journal to your unit file to make sure you capture output from the service you are running as well.