I am writing a tool (zxcV32/OpenRWC) that fetches wallpapers from Reddit and sets them to the monitor(s) using nitrogen.
To make it easy to install and run automatically, I have created a deb package and a systemd service.
When the service is started using
sudo systemctl start openrwc#$USER.service
nitrogen errors out with exit status 1. (No other error message). And yes, the exec installed by the deb package works fine when manually run from the terminal.
I have compared that the command run by the tool is precisely the same when run through the systemd service or terminal run.
Sample command
nitrogen --set-scaled /home/zxcv32/.config/OpenRWC/fz41kmzk1wj91.jpg --head=0
Service
[Unit]
Description=Reddit Wallpaper Changer for GNU/Linux
Requires=display-manager.service
After=display-manager.service
StartLimitIntervalSec=0
[Service]
Type=simple
ExecStart=/usr/bin/openrwc
Restart=always
RestartSec=5
User=%i
[Install]
WantedBy=graphical.target
What may be wrong with the service? I want the service to be the user's choice, if they want to run it or not.
BTW I found this question that claims that nitrogen works through a service. (maybe there is a difference between running nitrogen directly through system service and through a go funciton)
System: Debian 11 5.10.0-17-amd64
Found the issue.
Systemd does not have access to certain environment variables.
DISPLAY environment variable needs to be set in the openrwc#.service.
[Service]
Environment="DISPLAY=:0"
Related
I have a Ubuntu 16.04 LTS machine where I am successfully connected to the Jenkins server via JNLP connection. Steps I took for the connection are the following:
Create a directory in the slave called /home/MyUbuntu/Jenkins
Download both agent.jar and slave-agent.jnlp files into the
directory
Run this command from the terminal:
java -jar agent.jar -jnlpUrl http://my-jenkins-server:8080/computer/MyNode/slave-agent.jnlp -secret 6f8bb3250d6dbcda77979797997b0ea6bcaaa064785d558c0e4ea07d03 -workDir "/home/MyUbuntu/Jenkins"
The connection is successful.
Problem:
Once I close the terminal the connection gets disconnected.
Question:
How do I add this as a service in Ubuntu 16.04 LTS so whenever the machine is rebooted it starts as a startup???
If you use System D, add a file like this to /etc/systemd/system/.
[Unit]
Description=Jenkins slave connection
Wants=network.target
After=network.target
[Service]
ExecStart=java -jar agent.jar -jnlpUrl http://jenkinsurl:port/endpoint.jnlp -secret 4lph4num3r1cs3cr3t -workDir "/base/path/of/your/jenkinsjar"
Restart=always
WorkingDirectory=/base/path/of/your/jenkinsjar
User=my-user
Group=my-group
RestartSec=20s
[Install]
WantedBy=multi-user.target
Alias=jenkins.service
Permissions and ownership of the file may vary based on the service or OS. Long list files in /lib/systemd/system/ to get an idea of what perms you need or want (probably root:root 644).
Notice the command is the command that Jenkins provides for you when you create an agent jar. Just use that for ExecStart.
For user and group, I use the user that owns the directory where the Jenkins workspace is located. For example, if the Jenkins workspace is in /home/ubuntu, I specify ubuntu as user and group.
After that...
Prefix these with sudo if you're not running as root:
Probably a good idea to reload System D: systemctl daemon-reload.
Start: systemctl start jenkins.service. Notice this command pertains to the last line of the file Alias.
Enable it if you want the service to start with your computer: systemctl enable jenkins.service.
Here are the Git Gists I based my file on:
https://gist.github.com/unakatsuo/d4711f52a0ab0b9bc8010018149a7e84
https://gist.github.com/dragolabs/05dfe1c0899221ce51204dbfe7feecbb
I'm sure there's a lot more that can be done for the service config but in my case, I manage a lot of different servers and just need the thing to start automatically after boot!
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'd like to run syncthing as a daemon, trying to follow this hint here from the syncthing manual.
I'm running on Fedora 25 and syncthing 0.14.24.
The executable is pointed to via a symlink in /usr/bin/syncthing which can be executed by any user (tested this successfully).
To enable the service, I'm typing (myuser is replaced with my actual username in all of the below):
sudo systemctl enable sycnthing#myuser.service
Which returns:
Failed to lookup unit file state: Invalid argument
I don't understand what the error message means. How could I get to run syncthing as a daemon?
syncthing#myuser.service:
[Unit]
Description=Syncthing - Open Source Continuous File Synchronization for %I
Documentation=man:syncthing(1)
After=network.target
Wants=syncthing-inotify#myuser.service # I also commented this line out; didn't have an effect
[Service]
User=%i
ExecStart=/usr/bin/syncthing -no-browser -no-restart -logflags=0
Restart=on-failure
SuccessExitStatus=3 4
RestartForceExitStatus=3 4
[Install]
WantedBy=multi-user.target
I think myuser should be substituted for your actual username.
Arch wiki has a pretty good article:
System service
Running Syncthing as a system service ensures that it is running at startup even if the user has no active session, it is intended to be used on a server.
Enable and start the syncthing#myuser.service where myuser is the actual name of your user.
Credit: https://wiki.archlinux.org/index.php/Syncthing
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.
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.