I created a test server when i got a service that need to be started on boot after i got connected to NordVPN.
Anyway, i found that if i get also disconnected the service need to be restarted after the connection to the VPN is restored
Can you help me with this?
Thanks a lot
I created a service and I delayed the time at boot
[Unit]
Description=qBittorrent-nox service
Documentation=man:qbittorrent-nox(1)
Wants=network-online.target
After=network-online.target nss-lookup.target
[Service]
ExecStartPre=/bin/sleep 60
# if you have systemd < 240 (Ubuntu 18.10 and earlier, for example), you probably want to use Type=>
Type=exec
# change user as needed
User=root
# The -d flag should not be used in this setup
ExecStart=/usr/bin/qbittorrent-nox
Restart=on-failure
RestartSec=1s
# uncomment this for versions of qBittorrent < 4.2.0 to set the maximum number of open files to unl>
#LimitNOFILE=infinity
# uncomment this to use "Network interface" and/or "Optional IP address to bind to" options
# without this binding will fail and qBittorrent's traffic will go through the default route
# AmbientCapabilities=CAP_NET_RAW
[Install]
WantedBy=multi-user.target
The Restart directive specifies the conditions under which the service should be restarted. The default value for this directive is on-failure, which means that the service will only be restarted if it exits with a non-zero exit code. In your case, you can modify this directive to specify that the service should be restarted whenever the VPN connection is restored.
Here is an example of how you could modify the Restart directive in your unit file:
[Service]
...
Restart=on-failure-or-vpn-restored
With this configuration, your service will be restarted whenever it exits with a non-zero exit code, or whenever the VPN connection is restored.
Note that you will need to create a separate unit file to manage the VPN connection and specify this unit file as a dependency for your service's unit file. This will ensure that the service is only started after the VPN connection is established.
For example, you could add the following lines to your service's unit file to make it dependent on a VPN connection:
[Unit]
...
After=vpn.service
Wants=vpn.service
This will ensure that your service is only started after the vpn.service unit has been started successfully. You will need to create the vpn.service unit file and specify the necessary details for managing the VPN connection.
Related
I am using systemd services on an embedded system. I have a web service that needs to restart bluetooth everytime it restarts. How do I write the unit file for this. Also the service I have is put into systemd/user and not systemd/system.
I tried using PartOf=bluetooth.service but that didn't work.
[Unit]
# Human readable name of the unit
Description=Python User Service
#Link it to bluetooth
After=bluetooth.service
Requires=bluetooth.service
PartOf=bluetooth.service
[Service]
# Command to execute when the service is started
ExecStart=/usr/bin/python3 /home/root/MyServ.py
# Disable Python's buffering of STDOUT and STDERR, so that output from the
# service shows up immediately in systemd's logs
Environment=PYTHONUNBUFFERED=1
# Automatically restart the service if it crashes
Restart=on-failure
# Our service will notify systemd once it is up and running
#Type=notify
Type=simple
# Use a dedicated user to run our service
User=root
[Install]
# Tell systemd to automatically start this service when the system boots
# (assuming the service is enabled)
WantedBy=default.target
On [Unit] section you can reload services
PropagatesReloadTo=, ReloadPropagatedFrom=
A space-separated list of one or more units where reload requests on this unit will be propagated to, or reload requests on the
other unit will be propagated to this unit, respectively. Issuing a
reload request on a unit
will automatically also enqueue a reload request on all units that the reload request shall be propagated to via these two settings.
It sends bluetoothd command to reload via dbus. Not kill daemon, just reread configuration.
Or on [Service] section
ExecStopPost=/usr/bin/systemctl restart bluetooth.service
Or use override.conf on bluetooth.service
systemctl edit bluetooth.service
And here put
[Unit]
BindsTo=MyServ.service
I have installed the Node.js Extension and I can't get my app running. I have a Symfony 4 application and I am using socket.io for socket communication. Now I need to startup socket.js to startup my server. This file is located in the resources/js folder.
So I have setup Node.js as below:
Document Root: /application.domain.com/public
Application Mode: production
Application URL: This site is under development
Application Root: /application.domain.com
Application Startup File: resources/js/socket.js
Custom environment variables:
But when I start the application, it is not working. When I run the socket.js file from CLI (SSH connection) like this
/opt/plesk/node/8/bin/node socket.js
It is working fine. But now I need to keep my SSH connection alive and there is no check if socket.js is still running. I suppose the Node.js extension also takes care for that.
How can I use this Node.js extension to startup up my socket.js? Or how could I do this in another way?
OK, I fixed this another way with Systemd.
Found this on https://www.axllent.org/docs/view/nodejs-service-with-systemd/, so credits to Ralph Slooten.
Create the service file
/etc/systemd/system/nodeserver.service
Content
[Unit]
Description=Node.js Example Server
#Requires=After=mysql.service # Requires the mysql service to run first
[Service]
ExecStart=/usr/local/bin/node /opt/nodeserver/server.js
# Required on some systems
#WorkingDirectory=/opt/nodeserver
Restart=always
# Restart service after 10 seconds if node service crashes
RestartSec=10
# Output to syslog
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=nodejs-example
#User=<alternate user>
#Group=<alternate group>
Environment=NODE_ENV=production PORT=1337
[Install]
WantedBy=multi-user.target
Enable the service
systemctl enable nodeserver.service
Start the service
systemctl start nodeserver.service
I built a Nodejs project and now it runs smoothly.
I use forever service for running file in background but if server get restarted
the daemon won't be started automatically and should be started manually.
I want to run the daemon even the server get rebooted
You could add the forever command in .bash_profile so that every time the server restart, your command will simply be also executed.
nano ~/.bash_profile
forever start app.js # add this command to the file, or whatever command you are using.
source ~/.bash_profile # very important, else changes will not take effect
Next time, on your server restart, your command will also run, hence creating a daemon of your node script.
Note: This is maybe not the best solution, but the one I have got.
Update
As #dlmeetei, suggested, you can also start your nodejs app like a service so that we can use the features given by a linux service.
First create a file in /etc/systemd/system, like:
touch /etc/systemd/system/[your-app-name].service
nano /etc/systemd/system/[your-app-name].service
Then, add and edit the following script according to your relevance.
[Unit]
Description=Node.js Example Server
#Requires=After=mysql.service # Requires the mysql service to run first
[Service]
ExecStart=/usr/local/bin/node /opt/nodeserver/server.js
# Required on some systems
# WorkingDirectory=/opt/nodeserver
Restart=always
# Restart service after 10 seconds if node service crashes
RestartSec=10
# Output to syslog
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=nodejs-example
#User=<alternate user>
#Group=<alternate group>
Environment=NODE_ENV=production PORT=1337
[Install]
WantedBy=multi-user.target
Enable the service, it will marks the service for starting up on boot.
systemctl enable [your-app-name].service
Manage the service
systemctl start [your-app-name].service
systemctl stop [your-app-name].service
systemctl status [your-app-name].service # ensure your app is running
systemctl restart [your-app-name].service
Reference: https://www.axllent.org/docs/view/nodejs-service-with-systemd/
Thanks #dlmeetei for sharing the link.
I have a systemd service for my spring boot application connected to consul server, behind haproxy. consul provides consul-template to automatically update the service location in haproxy configuration file via consul-template command.
consul-template takes a template file and writes to the final haproxy configuration file and then reload the haproxy.
Now, consul-template process needs to run in background always along with my application, so that as the application comes up, it can detect new application startup and update its location in the configuration file.
Here is my systemd service file for this.
[Unit]
Description=myservice
Requires=network-online.target
After=network-online.target
[Service]
Type=forking
PIDFile=/home/dragon/myservice/run/myservice.pid
ExecStart=/home/dragon/myservice/bin/myservice-script start
ExecReload=/home/dragon/myservice/bin/myservice-script reload
ExecStop=/home/dragon/myservice/bin/myservice-script stop
ExecStartPost=consul-template -template '/etc/haproxy/haproxy.cfg.template:/etc/haproxy/haproxy.cfg:sudo systemctl reload haproxy'
User=dragon
[Install]
WantedBy=multi-user.target
Now, when I start systemctl start myservice, my application starts and the call to consul-template also works, but consul-template process doesn't go in background. I have to press Ctl+C and then systemctl comes back and I have both my application and consul-template process running.
Is there way to run the consul-template process in background specified in ExecStartPost?
I was trying to add & at the end of the ExecStartPost command, but then consul-template complains that it is an additional invalid argument and it fails.
I was also trying to make the command as /bin/sh -c "consul-template command here...", but then this also doesn't work. Even nohup in this command wasn't working.
Any help is really appreciated.
A workaround would be to have a bash file as your entrypoint, add all you need in there, then it will all magically work
I was trying to accomplish the same task. I wanted to fire off some HTTP requests to Tomcat once the service had started, so that I could warmup our servers ahead of the first user request.
I went through a lot of trial and error with using trying to use ExecStartPost to fire off an async process, but actually worked. By calling a shell script, I could trigger off background processes, but from my testing Systemd appears to kill the process thread when ExecStartPost finishes, so any child processes end up getting killed too. I tried various combinations of using &, setsid, nohup, etc, even some Perl to try and trigger off the an executable in it's own thread, but as soon as the shell script exite from ExecStartPost any processes running where killed. It's possible there's some solution that would work using ExecStartPost, but I couldn't find it.
However, what did work is creating a new service (like #divinedragon mentions) which piggy backs off the service I wanted to monitor (in this case Tomcat).
Since it took me a little research to get something working the way I wanted, I wanted to share my solution in case it helps someone.
The first step is to create a new service (e.g. /usr/lib/systemd/system/tomcat-service-listener.service):
[Unit]
Description=Tomcat start/stop event listener
# make sure to stop the service when Tomcat stops
BindsTo=tomcat.service
# waits for both Nginx & Tomcat to be started before this service is started
After=nginx.service tomcat.service
[Service]
Type=oneshot
ExecStart=/path/to/your/script.sh start
ExecStop=/path/to/your/script.sh stop
RemainAfterExit=yes
TimeoutStartSec=300
[Install]
# When the service is enabled, forces this service to start when Tomcat is started
WantedBy=tomcat.service
Some notes on what is happening here:
The BindsTo make sure the service gets stopped when Tomcat is stopped. This triggers the ExecStop command.
The After make sure that on server reboot, this service does not start until both Nginx & Tomcat have started.
The WantedBy will create the wants symlink for Tomcat (when the service is enabled), which will force Tomcat to start this service any time it's restarted.
The RemainAfterExit=yes is necessary for the ExecStop to work. If you only care about triggering something when you're service is started and don't care about when the service is stopped, you can set this to no and remove the ExecStop line.
Make the TimeoutStartSec long enough for whatever task you plan on running.
To get this service working, you then need to do the following:
# make the service executable
chmod 664 /usr/lib/systemd/system/tomcat-service-listener.service
# make Systemd aware of the new service
systemctl daemon-reload
# register the service so it's started/stopped with Tomcat
systemctl enable tomcat-service-listener.service
Now all you need script to trigger off the logic you want. In my case, I wanted to warmup some servers once Tomcat started so my /path/to/your/script.sh looks something like:
#!/bin/sh
SCRIPT_MODE="$1"
LOGFILE=/var/logs/myscript.log
log_message() {
local MESSAGE="$1"
echo "$(date '+%Y-%m-%d %H:%M:%S') $MESSAGE" >> "$LOGFILE"
return 0
}
warmup_server() {
local SERVER_ADDRESS="$1"
local SERVER_DESCRIPTION="$2"
log_message "Warming up $SERVER_DESCRIPTION..."
# we want to track the time it took to warm up the server
local START_TIME=$(date +%s)
# server restarts can take a while for all services to start, so we must retry long enough for all relevant services to start
HTTP_STATUS=$(curl --insecure --location --silent --show-error --fail --retry 60 --retry-delay 2 --retry-max-time 240 --output /dev/null --write-out "%{http_code}" '$SERVER_ADDRESS')
# we want to track the time it took to warm up the server
local TOTAL_STARTUP_TIME=$(($(date +%s)-$START_TIME))
log_message "$SERVER_DESCRIPTION started in $TOTAL_STARTUP_TIME seconds... (Status: $HTTP_STATUS)"
return 0
}
# monitor when Tomcat has stopped
if [ "$SCRIPT_MODE" == "stop" ]; then
log_message "Tomcat listener shutting down..."
exit 0
elif [ "$SCRIPT_MODE" == "start" ]; then
log_message "Tomcat listener started..."
fi
# servers to warm up
warmup_server 'https://127.0.0.1' 'Localhost #1'
warmup_server 'https://127.0.0.2' 'Localhost #2'
This seems to be working exactly as I want. The service starts up when the server is reboot and starting/stopping/restarting Tomcat fires off the expected events. Since it's independent of the Tomcat service, I can restart this warmup script if needed. It also doesn't delay the Tomcat startup time, since it is its own service, therefore running asynchronously like I wanted.
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.