I want to start my app as service from systemd but the app is not starting.
My unit file appstart.service looks like this:
[Unit]
Description=Application start
[Service]
Type=simple
User=ec2-user
ExecStart=/usr/bin/bash /home/ec2-user/project/restartScript.sh
SyslogIdentifier=App_start
[Install]
WantedBy=multi-user.target
RestartScript.sh should start the java app:
#!/bin/bash
export SPRING_PROFILES_ACTIVE="tst,development"
cd /home/ec2-user/project
pkill java
/usr/bin/java -jar /home/ec2-user/project/app.jar >>/home/ec2-user/project/web.log 2>>/home/ec2-user/project/web-error.log &
I am starting the app as a service this way using User Data on AWS EC2 instance:
#!/bin/bash
mkdir /home/ec2-user/project
cd /home/ec2-user/project
sudo wget -P /home/ec2-user/project/ https://tst.s3.eu-west-1.amazonaws.com/app.jar
chown -R ec2-user:ec2-user /home/ec2-user/project
sudo wget -P /home/ec2-user/project/ https://tst.s3.eu-west-1.amazonaws.com/restartScript.sh
sudo chmod 755 /home/ec2-user/project/restartScript.sh
cd /etc/systemd/system/
sudo wget /etc/systemd/system/ https://tst.s3.eu-west-1.amazonaws.com/appstart.service
sudo su
systemctl daemon-reload
systemctl enable appstart.service
systemctl start appstart.service
exit
The output I am getting when I start the EC2 instance this way is:
$ systemctl status appstart.service
● appstart.service - Application start
Loaded: loaded (/etc/systemd/system/appstart.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2022-08-25 13:35:52 UTC; 4min 19s ago
Process: 7328 ExecStart=/usr/bin/bash /home/ec2-user/project/restartScript.sh (code=exited, status=0/SUCCESS)
Main PID: 7328 (code=exited, status=0/SUCCESS)
Aug 25 13:35:52 ip-x-x-x-x.tst.local systemd[1]: Started Application start.
When I try to do
systemctl start appstart.service
Nothing changes. The application is not working.
Any idea why is this happening?
OS on the machine:
$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
Nothing seems to be wrong with this, the service is running and the application runs and finishes successfully. The Active state of the service becomes inactive (dead) in case of failure it should be Failed and Main PID is (code=exited, status=0/SUCCESS).
To verify that the service is running correct, write this line somewhere in RestartScript.sh:
echo "Test" > test.txt
After starting the service you will find the created file near RestartScript.sh file.
I managed to resolve the issue by changing the WantedBy section in appstart.service file to default.target.
Related
Simple systemd service not working as expected
Service name: test.service
[Unit]
Description=Test
ConditionEnvironment=STACK=prod
[Service]
Restart=always
ExecStart=/bin/bash -l -c 'echo "do prod stuff!!!"'
[Install]
WantedBy=default.target
sudo systemctl daemon-reload
sudo service test restart
journalctl -u test -f
Systemd is giving an error when I try to use the ConditionEnvironment setting.
Apr 27 13:16:33 ip-172-31-105-2 systemd[1]: Failed to start Test.
Apr 27 13:19:53 ip-172-31-105-2 systemd[1]: /etc/systemd/system/test.service:3: Unknown lvalue 'ConditionEnvironment' in section 'Unit'
Systemd ConditionEnvironment docs
While writing this question I found the answer.
The ConditionEnvironment setting was added in systemd version 246.
See release notes here
Seems Ubuntu is shipping with earlier versions.
ubuntu ~$ systemctl --version
systemd 237 (245.4-4ubuntu3.6)
Notes on updating systemd here: https://askubuntu.com/questions/627174/how-would-i-upgrade-systemd
I try to install vnc-server on my centos 7 server by following the steps below:
1) We install vnc-server
sudo yum install tigervnc-server
After, you’ve installed the program, login with the user you want to run the VNC program and issue the below command in terminal in order to configure a password for the VNC server.
su - your_user # If you want to configure VNC server to run under this user directly from CLI without switching users from GUI
$ vncpasswd
add a VNC service configuration file for your user via a daemon configuration file placed in systemd directory tree. In order to copy the VNC template file you need to run the following command with root privileges.
cp /lib/systemd/system/vncserver#.service /etc/systemd/system/vncserver#:1.service
On the next step edit the copied VNC template configuration file from /etc/systemd/system/ directory and replace the values to reflect your user as shown in the below
vi /etc/systemd/system/vncserver#\:1.service
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l my_user -c "/usr/bin/vncserver %i -geometry 1280x720"
PIDFile=/home/my_user/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
[Install]
WantedBy=multi-user.target
After you’ve made the proper changes to VNC service file, reload systemd system initialization program to pick up the new vnc configuration file and start the TigerVNC server.
systemctl daemon-reload
# systemctl start vncserver#:1
# systemctl status vncserver#:1
# systemctl enable vncserver#:1
Obtaining the following error
systemctl daemon-reload
[root#ns363691 ~]# systemctl start vncserver#:1
Job for vncserver#:1.service failed because a configured resource limit was exceeded. See "systemctl status vncserver#:1.service" and "journalctl -xe" for details.
[root#ns363691 ~]# systemctl status vncserver#:1
● vncserver#:1.service - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/vncserver#:1.service; disabled; vendor preset: disabled)
Active: failed (Result: resources) since mié 2019-11-13 02:09:07 CET; 14s ago
Process: 7605 ExecStart=/usr/sbin/runuser -l root -c /usr/bin/vncserver %i -geometry 1280x720 (code=exited, status=0/SUCCESS)
Process: 7593 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
nov 13 02:09:04 ns363691 systemd[1]: Starting Remote desktop service (VNC)...
nov 13 02:09:07 ns363691 systemd[1]: Can't open PID file /home/root/.vnc/ns363691:1.pid (yet?) after start: No such file or directory
nov 13 02:09:07 ns363691 systemd[1]: Failed to start Remote desktop service (VNC).
nov 13 02:09:07 ns363691 systemd[1]: Unit vncserver#:1.service entered failed state.
nov 13 02:09:07 ns363691 systemd[1]: vncserver#:1.service failed.
Any idea why the service does not start, what is this doing wrong? :(
I Wanted to run pygame script using systemd service for that
followed these steps to run a pygame script using systemd service
sudo systemctl daemon-reload
sudo systemctl enable service_name
sudo systemctl start service_name
and rebooted the system after that my-service don't want to run a pygame script for more understading
$ sudo journalctl -f -u rpi
-- Logs begin at Thu 2016-11-03 22:46:42 IST. --
Mar 28 12:19:11 raspberrypi systemd[1]: Started RPi-Service.
$sudo systemctl status rpi
rpi.service - RPi-Service
Loaded: loaded (/lib/systemd/system/rpi.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Thu 2019-03-28 12:19:14 IST; 22min ago
Process: 689 ExecStart=/home/pi/Documents/project1/allnewone (code=killed, signal=HUP)
Main PID: 689 (code=killed, signal=HUP)
My Service File
#rpi.service
[Unit]
Description= RPi-Service
After = multi-user.target
[Service]
Type = simple
ExecStart = /usr/bin/python3 /home/pi/Documents/project1/allnewone.py
Restart = on-abort
RestartSec = 5
KillMode = process
SendSIGHUP = no
[Install]
WantedBy=multi-user.target
Here is the solution
#rpi.service
[Unit]
Description= RPi-Service
After = multi-user.target
[Service]
Type = simple
Environment="DISPLAY=:0"
Environment="XAUTHORITY=/home/pi/.Xauthority"
ExecStart = /usr/bin/python3 /home/pi/Documents/project1/allnewone.py
Restart = always
RestartSec = 5
KillMode = process
SendSIGHUP = no
[Install]
WantedBy= graphical.target
I want to make a systemd unit for pgagnent.
I found only init.d script on this page http://technobytz.com/automatic-sql-database-backup-postgres.html, but I don't know how to exec start-stop-daemon in systemd.
I have written that unit:
[Unit]
Description=pgagent
After=network.target postgresql.service
[Service]
ExecStart=start-stop-daemon -b --start --quiet --exec pgagent --name pgagent --startas pgagent -- hostaddr=localhost port=5432 dbname=postgres user=postgres
ExecStop=start-stop-daemon --stop --quiet -n pgagent
[Install]
WantedBy=multi-user.target
But I get errors like:
[/etc/systemd/system/pgagent.service:14] Executable path is not absolute, ignoring: start-stop-daemon --stop --quiet -n pgagent
What is wrong with that unit?
systemd expects the ExecStart and ExecStop commands to include the full path to the executable.
start-stop-daemon is not necessary for services under systemd management. you will want to have it execute the underlying pgagent commands.
look at https://unix.stackexchange.com/questions/220362/systemd-postgresql-start-script for an example
If you installed pgagent with yum or apt-get, it should have created the systemd file for you. For example, on RHEL 7 (essentially CentOS 7), you can install PostgreSQL 12 followed by pgagent
sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
sudo yum install postgresql12
sudo yum install postgresql12-server
sudo yum install pgagent_12.x86_64
This installs PostgreSQL to /var/lib/pgsql/12 and pgagent_12 to /usr/bin/pgagent_12
In addition, it creates a systemd file at /usr/lib/systemd/system/pgagent_12.service
View the status of the service with systemctl status pgagent_12
Configure it to auto-start, then start it, with:
sudo systemctl enable pgagent_12
sudo systemctl start pgagent_12
Most likely the authentication will fail, since the default .service file has
ExecStart=/usr/bin/pgagent_12 -s ${LOGFILE} hostaddr=${DBHOST} dbname=${DBNAME} user=${DBUSER} port=${DBPORT}
Confirm with sudo tail /var/log/pgagent_12.log which will show
Sat Oct 12 19:35:47 2019 WARNING: Couldn't create the primary connection [Attempt #1]
Sat Oct 12 19:35:52 2019 WARNING: Couldn't create the primary connection [Attempt #2]
Sat Oct 12 19:35:57 2019 WARNING: Couldn't create the primary connection [Attempt #3]
Sat Oct 12 19:36:02 2019 WARNING: Couldn't create the primary connection [Attempt #4]
To fix things, we need to create a .pgpass file that is accessible when the service starts. First, stop the service
sudo systemctl stop pgagent_12
Examining the service file with less /usr/lib/systemd/system/pgagent_12.service shows it has
User=pgagent
Group=pgagent
Furthermore, /etc/pgagent/pgagent_12.conf has
DBNAME=postgres
DBUSER=postgres
DBHOST=127.0.0.1
DBPORT=5432
LOGFILE=/var/log/pgagent_12.log
Examine the /etc/passwd file to look for the pgagent user and its home directory: grep "pgagent" /etc/passwd
pgagent:x:980:977:pgAgent Job Schedule:/home/pgagent:/bin/false
Thus, we need to create a .pgpass file at /home/pgagent/.pgpass to define the postgres user's password
sudo su -
mkdir /home/pgagent
chown pgagent:pgagent /home/pgagent
chmod 0700 /home/pgagent
echo "127.0.0.1:5432:postgres:postgres:PasswordGoesHere" > /home/pgagent/.pgpass
chown pgagent:pgagent /home/pgagent/.pgpass
chmod 0600 /home/pgagent/.pgpass
The directory and file permissions are important. If you're having problems, you can enable debug logging by editing the service file at /usr/lib/systemd/system/pgagent_12.service to enable debug logging by updating the ExecStart command to have -l 2
ExecStart=/usr/bin/pgagent_12 -l 2-s ${LOGFILE} hostaddr=${DBHOST} dbname=${DBNAME} user=${DBUSER} port=${DBPORT}
After changing a .service file, things must be reloaded with sudo systemctl daemon-reload (systemd will inform you of this requirement if you forget it).
Keep starting/stopping the service and checking /var/log/pgagent_12.log Eventually, it will start properly and sudo systemctl status pgagent_12 will show
● pgagent_12.service - PgAgent for PostgreSQL 12
Loaded: loaded (/usr/lib/systemd/system/pgagent_12.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2019-10-12 20:18:18 PDT; 13s ago
Process: 6159 ExecStart=/usr/bin/pgagent_12 -s ${LOGFILE} hostaddr=${DBHOST} dbname=${DBNAME} user=${DBUSER} port=${DBPORT} (code=exited, status=0/SUCCESS)
Main PID: 6160 (pgagent_12)
Tasks: 1
Memory: 1.1M
CGroup: /system.slice/pgagent_12.service
└─6160 /usr/bin/pgagent_12 -s /var/log/pgagent_12.log hostaddr=127.0.0.1 dbname=postgres user=postgres port=5432
Oct 12 20:18:18 prismweb3 systemd[1]: Starting PgAgent for PostgreSQL 12...
Oct 12 20:18:18 prismweb3 systemd[1]: Started PgAgent for PostgreSQL 12.
I am trying to start a service named pigpiod.service via systemd. It invokes a script with three commands. The second one is left out. Why is this?
/etc/systemd/system/pigpiod.service:
[Unit]
Description=Starts pigpiod
Before=touchscreen.service
[Service]
ExecStart=/home/sysop/pigpiod.sh
[Install]
WantedBy=multi-user.target
/home/sysop/pigpiod.sh:
#!/bin/sh
touch /home/sysop/before_pigpiod
/usr/bin/pigpiod
touch /home/sysop/after_pigpiod
When restarting the machine the two files get created in /home/sysop/, but pigpiod is not starting.
When starting the service manually via sudo systemctl start pigpiod the same happens.
When running sudo /home/sysop/pigpiod.sh manually pigpiod is actually starting!
This is the output of sudo systemctl status pigpiod -l right after boot:
● pigpiod.service - Starts pigpiod
Loaded: loaded (/etc/systemd/system/pigpiod.service; enabled)
Active: inactive (dead) since Sat 2017-09-16 20:02:03 UTC; 2min 29s ago
Process: 440 ExecStart=/home/sysop/pigpiod.sh (code=exited, status=0/SUCCESS)
Main PID: 440 (code=exited, status=0/SUCCESS)
Sep 16 20:02:02 kivypie systemd[1]: Starting Starts pigpiod...
Sep 16 20:02:02 kivypie systemd[1]: Started Starts pigpiod.
Why is it, that systemd skips the execution of /usr/bin/pigpiod, but manually running the script as root does not?
My system: Raspberry Pi Model 3B, Raspbian GNU/Linux 8 (jessie)
pigpiod forks without the -g option. So use Type = forking or use pigpiod -g
[Unit]
Description=Starts pigpiod
Before=touchscreen.service
[Service]
ExecStart=/home/sysop/pigpiod.sh
Type=forking
[Install]
WantedBy=multi-user.target