Jar as a Service in RHEL 8.2 - Not Starting - java

I have a spring boot uber jar that I need to run as a service in RHEL 8.2 environment.
The service file created in /etc/systemd/system/myapp.service is as simple as this:
[Unit]
Description=myapp
[Service]
User=appuser
WorkingDirectory=/home/appuser
ExecStart=/usr/bin/java -Xmx256m -jar -Dspring.profiles.active=test /home/appuser/myapp.jar
SuccessExitStatus=143
TimeoutStopSec=10
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Now when I try to start the service and check the status using the below commands I get the below error:
[root#myappdev01 /etc/systemd/system]# sudo systemctl status myapp
myapp.service - myapp
Loaded: loaded (/etc/systemd/system/myapp.service; disabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Fri 2020-09-11 23:48:26 +04; 5s ago
Process: 273497 ExecStart=/usr/bin/java -jar -Dspring.profiles.active=test /home/appuser/myapp.jar (code=exited, status=1/FAILURE)
Main PID: 273497 (code=exited, status=1/FAILURE)
Sep 11 23:48:26 myappdev01.server systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
Sep 11 23:48:26 myappdev01.server systemd[1]: myapp.service: Failed with result 'exit-code'.
journatlctl -u myapp.service also doesn't help much.
What have I done wrong here?

The jar you're using needs to come directly after the -jar flag:
ExecStart=/usr/bin/java -Xmx256m -Dspring.profiles.active=test -jar /home/appuser/myapp.jar

Related

Sonarqube on Browser in Linux

I have installed and configured the sonarqube on the server and created a symlink with systemd/systemctl, it properly running in terminal without any error but not running on browser even with default port. The version i have tried is 8.71 and 9, but in both it doesn't work, i have configured the postgres credentials and all in "sonar.properties"
but even after anything it doesn't work,
sonarqube#sonar2020:~/sonarqube-8.3.1.34397$
bin/linux-x86-64/sonar.sh start\
; Starting SonarQube... Started SonarQube. sonarqube#sonar2020:~/sonarqube-8.3.1.34397$ bin/linux-x86-64/sonar.sh
status SonarQube is running (12957).
sonarqube#sonar2020:~/sonarqube-8.3.1.34397$ sudo nano
/etc/systemd/system/sonar.service
sonarqube#sonar2020:~/sonarqube-8.3.1.34397$ sudo systemctl enable
sonar Created symlink
/etc/systemd/system/multi-user.target.wants/sonar.service →
/etc/systemd/system/sonar.service.
sonarqube#sonar2020:~/sonarqube-8.3.1.34397$ sudo systemctl start
sonar.service sonarqube#sonar2020:~/sonarqube-8.3.1.34397$ sudo
systemctl status sonar.service ● sonar.service - SonarQube service
Loaded: loaded (/etc/systemd/system/sonar.service; enabled; vendor
preset: enabled) Active: active (running) since Tue 2022-11-22
09:12:15 UTC; 1s ago Process: 13574
ExecStop=/home/sonarqube/sonarqube-8.3.1.34397/bin/linux-x86-64/sonar.sh
stop (code=exited, status=0/SUCCESS) Process: 13634
ExecStart=/home/sonarqube/sonarqube-8.3.1.34397/bin/linux-x86-64/sonar.sh
start (code=exited, status=0/SUCCESS) Main PID: 13697 (wrapper)
Tasks: 19 (limit: 4915) CGroup: /system.slice/sonar.service
├─13697 /home/sonarqube/sonarqube-8.3.1.34397/bin/linux-x86-64/./wrapper
/home/sonarqube/sonarqube-8.3.1.34397/bin/linux-x86-64/../../conf/wrapper.conf
wrapper.syslog.ident=SonarQube
wrapper.pidfile=/home/sonarqube/sonarqube-8.3.1.34397/bin/linux-x86-
└─13702 java -Dsonar.wrapped=true -Djava.awt.headless=true -Xms8m -Xmx32m -Djava.library.path=./lib -classpath ../../lib/jsw/wrapper-3.2.3.jar:../../lib/common/picocontainer-2.15.jar:../../lib/common/lucene-join-7.7.2.jar:../../lib/common/sonar-db-mig
Nov 22 09:12:14 sonar2020 systemd[1]: sonar.service: Scheduled restart
job, restart counter is at 3. Nov 22 09:12:14 sonar2020 systemd[1]:
Stopped SonarQube service. Nov 22 09:12:14 sonar2020 systemd[1]:
Starting SonarQube service... Nov 22 09:12:14 sonar2020
sonar.sh[13634]: Starting SonarQube... Nov 22 09:12:15 sonar2020
sonar.sh[13634]: Started SonarQube. Nov 22 09:12:15 sonar2020
systemd[1]: Started SonarQube service.
Now whenever i try to open it on browser, it shows connection refused. How can it be refused when all ports are open in local??

Unable to start the jenkins in amazon linux machine

I try to start the Jenkins, im facing this error
[root#ip-10-0-1-245 ~]# systemctl start jenkins
Job for jenkins.service failed because the control process exited with error code. See "systemctl status jenkins.service" and "journalctl -xe" for details.
and my java version is
openjdk version "11.0.13" 2021-10-19 LTS
And show only the activating status
[root#ip-10-0-1-245 ~]# systemctl status jenkins
● jenkins.service - Jenkins Continuous Integration Server
Loaded: loaded (/usr/lib/systemd/system/jenkins.service; enabled; vendor preset: disabled)
Active: activating (start) since Sun 2022-05-08 14:46:00 UTC; 169ms ago
Main PID: 20507 (java)
CGroup: /system.slice/jenkins.service
└─20507 /usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/jenkins.war --webroot=%C/jenkins/war --httpPort=...
May 08 14:46:00 ip-10-0-1-245.ap-south-1.compute.internal systemd[1]: Starting Jenkins Continuous Integration Server...
kindly help to resolve this issue

systemd java file service managment

I have this java file, it has to be executed using the following command otherwise it defaults to ipv6 and effectively useless for my use-case
-jar Djava.net.preferIPv4Stack=true EdOwl-Springboot.jar
I tried following this guide: https://computingforgeeks.com/how-to-run-java-jar-application-with-systemd-on-linux/
However using this shows:
root#edowl:~# systemctl status EdOwl-Springboot.service
● EdOwl-Springboot.service - EdowlSpringboot
Loaded: loaded (/etc/systemd/system/EdOwl-Springboot.service; disabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Tue 2022-02-22 11:28:26 UTC; 10s ago
Main PID: 186854 (code=exited, status=203/EXEC)
Tasks: 0 (limit: 614)
Memory: 0B
CGroup: /system.slice/EdOwl-Springboot.service
Feb 22 11:28:36 edowl.online systemd[1]: EdOwl-Springboot.service: Scheduled restart job, restart counter is at 125919.
Feb 22 11:28:36 edowl.online systemd[1]: Stopped EdowlSpringboot.
Feb 22 11:28:36 edowl.online systemd[1]: Started EdowlSpringboot.
Feb 22 11:28:36 edowl.online systemd[186888]: EdOwl-Springboot.service: Failed to execute command: No such file or directory
Feb 22 11:28:36 edowl.online systemd[186888]: EdOwl-Springboot.service: Failed at step EXEC spawning /bin/java: No such file or directory
Feb 22 11:28:36 edowl.online systemd[1]: EdOwl-Springboot.service: Main process exited, code=exited, status=203/EXEC
Feb 22 11:28:36 edowl.online systemd[1]: EdOwl-Springboot.service: Failed with result 'exit-code'.
the service file is as follows:
[Unit]
Description=EdowlSpringboot
[Service]
WorkingDirectory=/home
ExecStart=/bin/java -Xms128m -Xmx256m -jar Djava.net.preferIPv4Stack=true EdOwl-Springboot.jar
Type=simple
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
The file is located in the /home dir
I am certain it is the exec start line that is messing this up, is it necessary to state: /bin/java -Xms128m -Xmx256mor am I messing up something else here?
Suggestions are welcome cheers
The JVM argument java.net.preferIPv4Stack should be prefixed with -D instead you have D
Also, as others pointed out in comments check your java path it might be /usr/bin/java.
So, change the command to /usr/bin/java -Xms128m -Xmx256m -jar -Djava.net.preferIPv4Stack=true EdOwl-Springboot.jar

Tomcat 9 no longer starting using systemctl but will start manually

Been digging on this for a while. I reviewed multiple articles on this issue. This one was the closest:
Tomcat 8 on CentOS 7 does not start as service (but it starts manually ....)
The difference being that I am running Tomcat 9.0.33. Here are the particulars:
java version "1.8.0_121"\
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)\
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)\
Tomcat 9.0.33
NAME="CentOS Linux"\
VERSION="7 (Core)"\
ID="centos"\
ID_LIKE="rhel fedora"\
VERSION_ID="7"\
PRETTY_NAME="CentOS Linux 7 (Core)"\
ANSI_COLOR="0;31"\
CPE_NAME="cpe:/o:centos:centos:7"\
HOME_URL="https://www.centos.org/"\
BUG_REPORT_URL="https://bugs.centos.org/"\
CENTOS_MANTISBT_PROJECT="CentOS-7"\
CENTOS_MANTISBT_PROJECT_VERSION="7"\
REDHAT_SUPPORT_PRODUCT="centos"\
REDHAT_SUPPORT_PRODUCT_VERSION="7"\
As a side note, everything was starting normally with no issues until recently. As far as I know there haven't been any major changes to the environment. But, when I ran the "systemctl restart" command recently, the startup began to fail. There are 5 instances of Tomcat 9.0.33 running at different ports and paths and those have not changed. I have not restarted two of the instance (afraid they won't start) the other three flat out won't start. Details below:
Systemd unit file for tomcat\
[Unit]\
Description=Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
After=syslog.target network.target
[Service]\
Type=forking
Environment=JAVA_HOME=/opt/jdk1.8.0_121/jre\
Environment=CATALINA_PID=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/temp/tomcat.pid\
Environment=CATALINA_HOME=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment=CATALINA_BASE=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment='CATALINA_OPTS=-Xms1024m -Xmx2048m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=8 -server -Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n'\
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -Duser.timezone=GMT -Dfile.encoding=UTF-8'
ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh\
ExecStop=/bin/kill -15 $MAINPID
User=tomcat\
Group=tomcat\
UMask=0007
[Install]\
WantedBy=multi-user.target\
Results when running systemctl start liferayuat
● liferayuat.service - Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
Loaded: loaded (/etc/systemd/system/liferayuat.service; enabled; vendor preset: disabled)\
Active: failed (Result: exit-code) since Sat 2020-12-05 08:44:08 CST; 3s ago\
Process: 10891 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=1/FAILURE)\
Process: 10851 ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh \(code=exited, status=0/SUCCESS)\
Main PID: 10861 (code=exited, status=0/SUCCESS)
Dec 05 08:44:08 systemd[1]: Starting Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT...\
Dec 05 08:44:08 startup.sh[10851]: Existing PID file found during start.\
Dec 05 08:44:08 startup.sh[10851]: Removing/clearing stale PID file.\
Dec 05 08:44:08 startup.sh[10851]: Tomcat started.\
Dec 05 08:44:08 systemd[1]: Started Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT.\
Dec 05 08:44:08 systemd[1]: liferayuat.service: control process exited, code=exited status=1\
Dec 05 08:44:08 systemd[1]: Unit liferayuat.service entered failed state.\
Dec 05 08:44:08 systemd[1]: liferayuat.service failed.
Then the ONLY thing in catalina.out:
Listening for transport dt_socket at address: 5000\
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina\
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)\
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)\
at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:261)\
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:443)\
So, when I start the instance with systemctl start it will fail. But if I run this command (as root...) then it will start:
/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh
If I run that full commmand AS tomcat it doesn't start with the same error. So, it appears that the issue is permissions. The tomcat user and group are owners of all files and folders. But, somehow, the tomcat user either doesn't have permissions or the path gets jacked up so that the class files can't be found. I followed the suggestions in the article I referenced above but the changes had no impact.
I tripped across one article on SELINX that seemed to point to an issue there. This are the SELINUX settings:
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31\
The workaround to keep the instances running is just to manually start them but what is causing systemctl start NOT to work? I suspect permissions but I sure as heck can't see why since everything is owned by tomcat:tomcat
So, this is self-inflicted as most "mysteries" are. I still cannot account for some of the differences I see when looking into SELinux contexts between the instances but the REAL cause was subtle (to me). Permissions on the {tomcat root}/lib and {tomcat root}/lib/ext had no execute permissions. That may have been due to a jar that was added recently and then needed to be updated by owner and permissions. In any case, the original issue resulted in many trial and error attempts to fix it which complicated matters further.
I discovered the solution by doing a folder by folder, file by file comparison between working and non-working instances. Apparently the new jar and the owner/permission changes were applied to all but the production version.
Thanks for the suggestions.

Unable to install Jetty9 as a service in Ubuntu

I've followed the docs in order to install Jetty9 as a service but whenever I run
service jetty start
It would fail with no messages, my JETTY_HOME is /opt/jetty9, contains the home distribution for version 9.4.14. I've also created my JETTY_BASE at /usr/share/jetty9 with my webapp and modules.
Both Jetty Home and Base are owned by the user jetty. I've then symlinked to my init.d folder as:
ln -s /opt/jetty9/bin/jetty.sh /etc/init.d/jetty
Then I created a /etc/default/jetty file with the following content:
# change to 1 to prevent Jetty from starting
NO_START=0
# change to 'no' or uncomment to use the default setting in /etc/default/rcS
VERBOSE=yes
# Run Jetty as this user ID (default: jetty)
# Set this to an empty string to prevent Jetty from starting automatically
JETTY_USER=jetty
# The home directory of the Java Runtime Environment (JRE). You need at least
# Java 6. If JAVA_HOME is not set, some common directories for OpenJDK and
# the Oracle JDK are tried.
#JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
# Extra options to pass to the JVM
#JAVA_OPTIONS="-Xmx256m -Djava.awt.headless=true"
# Timeout in seconds for the shutdown of all webapps
#JETTY_SHUTDOWN=30
# Additional arguments to pass to Jetty
#JETTY_ARGS=
# Jetty uses a directory to store temporary files like unpacked webapps
TMPDIR=/opt/jetty9/tmp
JETTY_HOME=/opt/jetty9
JETTY_BASE=/usr/share/jetty9
# Default for number of days to keep old log files in /var/log/jetty9/
#LOGFILE_DAYS=14
# If you run Jetty on port numbers that are all higher than 1023, then you # do not need authbind. It is used for binding Jetty to lower port numbers.
# (yes/no, default: no)
#AUTHBIND=yes
JETTY_HOST=0.0.0.0
If I start Jetty using java -jar $JETTY_HOME/start.jar in my base folder it would work with no problem. Also, if I run
service jetty supervise
It would also run with no issues, but when I call start it fails with:
root#app:/usr/share/jetty9# service jetty start
Job for jetty.service failed because the control process exited with error code.
See "systemctl status jetty.service" and "journalctl -xe" for details.
root#app:/usr/share/jetty9# service jetty status
● jetty.service - LSB: Jetty start script.
Loaded: loaded (/etc/init.d/jetty; generated)
Active: failed (Result: exit-code) since Mon 2018-12-03 15:05:26 UTC; 14s ago
Docs: man:systemd-sysv-generator(8)
Process: 21162 ExecStop=/etc/init.d/jetty stop (code=exited, status=0/SUCCESS)
Process: 21202 ExecStart=/etc/init.d/jetty start (code=exited, status=1/FAILURE)
Dec 03 15:05:22 app systemd[1]: Stopped LSB: Jetty start script..
Dec 03 15:05:22 app systemd[1]: Starting LSB: Jetty start script....
Dec 03 15:05:26 app jetty[21202]: Starting Jetty: FAILED Mon Dec 3 15:05:26 UTC 2018
Dec 03 15:05:26 app systemd[1]: jetty.service: Control process exited, code=exited status=1
Dec 03 15:05:26 app systemd[1]: jetty.service: Failed with result 'exit-code'.
Dec 03 15:05:26 app systemd[1]: Failed to start LSB: Jetty start script..
This is the output of service jetty check:
root#app:/usr/share/jetty9# service jetty check
Jetty NOT running
JAVA = /usr/bin/java
JAVA_OPTIONS = -Djetty.home=/opt/jetty9 -Djetty.base=/usr/share/jetty9 -Djava.io.tmpdir=/opt/jetty9/tmp
JETTY_HOME = /opt/jetty9
JETTY_BASE = /usr/share/jetty9
START_D = /usr/share/jetty9/start.d
START_INI = /usr/share/jetty9/start.ini
JETTY_START = /opt/jetty9/start.jar
JETTY_CONF = /opt/jetty9/etc/jetty.conf
JETTY_ARGS = jetty.state=/usr/share/jetty9/jetty.state jetty-started.xml
JETTY_RUN = /var/run/jetty
JETTY_PID = /var/run/jetty/jetty.pid
JETTY_START_LOG = /var/run/jetty/jetty-start.log
JETTY_STATE = /usr/share/jetty9/jetty.state
JETTY_START_TIMEOUT = 60
RUN_CMD = /usr/bin/java -Djetty.home=/opt/jetty9 -Djetty.base=/usr/share/jetty9 -Djava.io.tmpdir=/opt/jetty9/tmp -jar /opt/jetty9/start.jar jetty.state=/usr/share/jetty9/jetty.state jetty-started.xml
Any ideas?
UPDATE
Changing the user in /etc/default/jetty to root would solve the issue, but this is not a solution, isn't it?
# Run Jetty as this user ID (default: jetty)
# Set this to an empty string to prevent Jetty from starting automatically
JETTY_USER=root
I finally got this working, the jetty user should have permissions to the following folders and /usr/sbin/nologin as shell as described here.
JETTY_HOME
JETTY_BASE
/var/run/jetty <-- couldn't find a reference to this folder in the docs
And add the following to your /etc/default/jetty:
JETTY_SHELL=/bin/sh
JETTY_LOGS=/usr/share/jetty9/logs
JETTY_START_LOG=/usr/share/jetty9/logs/jetty-start-log.log
Also you should double check that there are no remaining log files owned by other user than jetty in your folders.

Categories

Resources