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
Related
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"
So today one of our application servers were restarted due to some issue and after restart we found that our application services were not running.
I want to create one script which will check these below services after a server restart and start them automatically if found stopped:
1st Service with Path : /opt/bea/config/nm/nm-sdi-abc/beaNMctl.sh
2nd service TOMCAT - Path : /opt/apache/tomcat/bin --- Service name startup.sh
Catch here is 1st service can be started with the normal id account that i use.
But 2nd service can be restarted after logging into a different service account on same server and network. Like below:
[x201691#abc bin]$ su - apache
Password:
-bash-2.05b$ cd /
-bash-2.05b$ cd /opt/apache/tomcat/bin/
-bash-2.05b$ ./startup.sh
Can someone help?
Also we are not root users.
You can write a shell script:
echo YOUR_PASSWORD | sudo -S su
cd /opt/apache/tomcat/bin/
./startup.sh
Save this as a file somewhere you have access and add the following cron entry:
#reboot MYPATH/myscript.sh >> MYPATH/script.log 2>&1
script.log will contain any output or errors from your script. You can add date command to the script to help with information on when it was run. More information on cron here.
Also, if you have concern with putting password in the script, you can go through the discussion here.
Preferred approach when installing Tomcat in Linux is to make Tomcat as a service.
This will ensure your service is started after reboot
1. Create the service file with the following command:
touch /etc/systemd/system/tomcat.service
2. Assign the relevant rights to the file you created:
chmod 664 /etc/systemd/system/tomcat.service
3. Paste the following content in the file while adapting it to your configuration:
[Unit]
Description=Application description/name
After=syslog.target network.target
[Service]
Type=forking
User=tomcat
ExecStart=$CATALINA_HOME/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
Install]
WantedBy=multi-user.target
4. Reload the service daemon:
systemctl daemon-reload
5. Start the service:
systemctl start tomcat
6. To check status :
systemctl status tomcat
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'm new to the concept of systemd unit files in Centos 7 but need to start up the MATLAB license manager at boot. MATLAB doesn't offer a specific solution on how to do this, and the following seems to work but asks for a password when typing systemctl start license-manager and systemctl stop license-manager. Is that expected?
Note this does need to run as a specific user and not as root.
Here is my /etc/systemd/system/license-manager.servicefile:
[Unit]
Description=MATLAB FlexLM license manager
[Service]
Type=forking
ExecStart=/usr/local/MATLAB/R2016a/etc/lmstart
ExecStop=/usr/local/MATLAB/R2016a/etc/lmdown
KillMode=none
Restart=on-failure
RestartSec=90
User=lmlicenseuser
[Install]
WantedBy=multi-user.target
You can try Crontab
bash$ crontab -e
then add the following line
#reboot /usr/local/MATLAB/R201Xx/etc/lmstart
This should resolve your issue.
Traditionally it is always expected for non-root users to be asked for a password when running commands as other users, yes.
However, because you have specified that it is a dependency of multi-user.target, it should always be started automatically whenever you reboot in future, so you shouldn't need to enter the password in future.
If for some reason you do still need to control it manually in future, you can use sudo and edit /etc/sudoers to allow those two particular commands to be run without a password, using NOPASSWD.
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.