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 ?
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'm using RaspberryPi (3B+) Linux ARM IOT board which OS is Debian Stretch 9, and my console application is developed on .NET CORE 2.1.
My application is quite simple by just open several TCP connections to a remote server, after build my application (with symbol Linux ARM), I can see the output files include myApp, and myApp.dll. I've done lots of run via directly command line:
pi#raspberrypi:~/Desktop/myApp $ ./myApp
or:
pi#raspberrypi:~/Desktop/myApp $ dotnet ./myApp.dll
which both runs well, and the CPU via top (process name is myApp, while the latter is dotnet) are all less than 20.
Today I want to add my app to daemon for keep runing all the way, this is my daemon serivce file under /etc/systemd/system:
[Unit]
Description=myApp for controlling Tcp devices
[Service]
WorkingDirectory=/home/pi/Desktop/myApp
#
ExecStart=/usr/local/bin/dotnet myApp.dll
Restart=always
# Restart service after 10 seconds if this service crashes:
RestartSec=10
SyslogIdentifier=myApp
# User=pi
[Install]
WantedBy=multi-user.target
after enable, start the service via systemctl command, I can see the app is running via top (the process name is dotnet), but now the CPU is quite high (for process dotnet) which is over 100.
Any idea for how the CPU rises, and is there a way to keep my process name back rather than dotnet?
Finally I found the cause is the code in Main:
static void Main(string[] args)
{
//my business logic code
//balabala
while (true)
Console.ReadLine();
}
that means in deamon mode, the Console.ReadLine() always can read a space and cause an infinite loop, which consumed the CPU, I'm not sure how that space coming, is that .NET CORE bug?
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.
We have an embedded target environment (separate from out host build environment) in which systemd is running but not cron.
We also have a script which, under most systems, I would simply create a cron entry to run it every five minutes.
Now I know how to create a service under systemd but this script is a one-shot that exits after it's done its work. What I'd like to do is have it run immediately on boot (after the syslog.target, of course) then every five minutes thereafter.
After reading up on systemd timers, I created the following service file is /lib/systemd/system/xyzzy.service:
[Unit]
Description=XYZZY
After=syslog.target
[Service]
Type=simple
ExecStart=/usr/bin/xyzzy.dash
and equivalent /lib/systemd/system/xyzzy.timer:
[Unit]
Description=XYZZY scheduler
[Timer]
OnBootSec=0min
OnUnitActiveSec=5min
[Install]
WantedBy=multi-user.target
Unfortunately, when booting the target, the timer does not appear to start since the output of systemctl list-timers --all does not include it. Starting the timer unit manually seems to work okay but this is something that should be run automatically with user intervention.
I would have thought the WantedBy would ensure the timer unit was installed and running and would therefore start the service periodically. However, I've noticed that the multi-user.target.wants directory does not actually have a symbolic link for the timer.
How is this done in systemd?
The timer is not active until you actually enable it:
systemctl enable xyzzy.timer
If you want to see how it works before rebooting, you can also start it:
systemctl start xyzzy.timer
In terms of doing that for a separate target environment where you aren't necessarily able to easily run arbitrary commands at boot time (but do presumably control the file system content), you can simply create the same symbolic links (in your development area) that the enable command would do.
For example (assuming SYSROOT identifies the root directory of the target file system):
ln -s ${SYSROOT}/lib/systemd/system/xyzzy.timer
${SYSROOT}/lib/systemd/system/multi-user.target.wants/xyzzy.timer
This will effectively put the timer unit into an enabled state for the multi-user.target, so systemd will start it with that target.
Also, normally your custom files would be stored in /etc/systemd/system/. The equivalent lib directory is intended to host systemd files installed by packages or the OS.
If it's important that your cron job run precisely every 5 minutes, you should check the accuracy because systemd's monotonic timers can slip over time
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.