How to configure system environment variables inside one Jetty application?
e.g. For database connection details, putting it in file and checking it into cvs is bad idea. For that reason using system environment is one way to go. While the system environment variables are defined in /etc/environments file or .bashrc/.zshrc file , in Jetty application, doing System.getenv("variable_name") won't give anything. It will result in null.
I have read this question: Configuring a Jetty application with env variables which concludes that which tells that Jetty doesn't support System.getenv() and not even in start.ini file.
And jetty and etc environment on ubuntu 12.10 which says In the jetty.sh script you can source the /etc/environment file and they will be present. which I tried and didn't get the values as expected meaning it gave me only null.
If I can't use the default System.getenv() or in any .ini file then how to specify credentials such as Database connection etc ?
Not supporting System.getenv() is not a Jetty thing, but a Java thing.
There are ton of restrictions around System.getenv() and your environment, making it nearly useless in all but the most naive and basic test case. (eg: multiline values are not supported. multiline entries can break parsing. keys without values are not supported. keys without values can often merge with next key during parsing. entries with non US-ASCII characters are not supported. entries with control characters are not supported.)
The common technique when using System Environment variables with Java programs is to use the shell specific techniques to obtain the values and inject them either on the command line, or into a ini file format for Jetty to then use.
Depending on your technique, these values would either show up as Jetty properties, or as Java System Properties.
Just created a project to demonstrate 4 ways to accomplish this at
https://github.com/jetty-project/jetty-external-config
External Configuration Properties with Jetty
Demonstration of how to configure simple properties that can be accessed
by Servlets within Jetty.
This demonstration shows 4 different ways to configure a property
at runtime, that can then be read by the Servlet running within
Jetty.
The props.war
This is a simple war file with a single HttpServlet and a WEB-INF/web.xml
[jetty-external-config]$ jar -tvf target/props.war
0 Mon Feb 23 09:02:14 MST 2015 META-INF/
131 Mon Feb 23 09:02:14 MST 2015 META-INF/MANIFEST.MF
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/
0 Mon Feb 23 09:02:14 MST 2015 WEB-INF/classes/org/eclipse/demo/
2188 Mon Feb 23 09:02:12 MST 2015 WEB-INF/classes/org/eclipse/demo/PropsServlet.class
572 Mon Feb 23 08:45:22 MST 2015 WEB-INF/web.xml
See PropsServlet.java for details of behavior.
Just compile the top level and the war file will be built and placed in all of the demo jetty.base locations for this project.
Example #1: Basic Command Line
The /base-command-line project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp. no extra configuration is done by the on-disk configuration.
If you start it up like so ...
[base-command-line]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized #290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext#6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector#67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started #555ms
you'll see that it has started up and deployed to the /props context path.
From here you can test for properties in the servlet via tooling like wget or curl.
Example:
$ curl http://localhost:9090/props/props
[java.runtime.name] = Java(TM) SE Runtime Environment
[sun.boot.library.path] = /home/joakim/java/jvm/jdk-7u75-x64/jre/lib/amd64
[java.vm.version] = 24.75-b04
[java.vm.vendor] = Oracle Corporation
[java.vendor.url] = http://java.oracle.com/
...
[file.separator] = /
[java.vendor.url.bug] = http://bugreport.sun.com/bugreport/
[sun.io.unicode.encoding] = UnicodeLittle
[sun.cpu.endian] = little
[sun.desktop] = gnome
[sun.cpu.isalist] =
You can even request a specific property ..
$ curl http://localhost:9090/props/props/user.timezone
[user.timezone] = America/Phoenix
Lets stop the server and run it with a system property of our choice.
Notice the -Dfoo=bar ?
[base-command-line]$ java -Dfoo=bar -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:15:46.088:INFO::main: Logging initialized #290ms
2015-02-23 09:15:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
2015-02-23 09:15:46.235:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/joakim/code/stackoverflow/jetty-external-config/base-command-line/webapps/] at interval 1
2015-02-23 09:15:46.325:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /props, did not find org.eclipse.jetty.jsp.JettyJspServlet
2015-02-23 09:15:46.343:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext#6e7f61a3{/props,file:/tmp/jetty-0.0.0.0-9090-props.war-_props-any-27537844855769703.dir/webapp/,AVAILABLE}{/props.war}
2015-02-23 09:15:46.353:INFO:oejs.ServerConnector:main: Started ServerConnector#67cd35c5{HTTP/1.1}{0.0.0.0:9090}
2015-02-23 09:15:46.353:INFO:oejs.Server:main: Started #555ms
and look for it via curl ...
$ curl http://localhost:9090/props/props/foo
[foo] = bar
That demonstrates access of a property that was specified via the command line, now lets look at the other choices.
Example #2: Using start.ini
The /base-startini project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains a foo.ish property.
Lets start up Jetty and try our props servlet access again ...
[base-startini]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:16:46.088:INFO::main: Logging initialized #290ms
2015-02-23 09:16:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.ish
[foo.ish] = bar
Example #3: Using start.d optional ini
The /base-startd project contains a simple start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains no extra properties that we are interested in.
The start.d/myconf.ini contains a property called foo.d that we are interested in.
Lets start up Jetty and try our props servlet access again ...
[base-startd]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:19:46.088:INFO::main: Logging initialized #290ms
2015-02-23 09:19:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.d
[foo.d] = over here
Example #4: Using --include-jetty-dir optional config
The /base-jettyinclude project contains a new start.ini which starts jetty on port 9090, and deploys the webapp.
This start.ini also contains no extra properties that we are interested in.
However, the start.ini uses the --include-jetty-dir=../jettydir optional configuration that points to an entirely new interrim jetty.base configuration source.
The ../jettydir/start.ini contains a property called foo.jetty.dir that we are interested in.
Lets start up Jetty and try our props servlet access again ...
[base-jettyinclude]$ java -jar /path/to/jetty-distribution-9.2.7.v20150116/start.jar
2015-02-23 09:24:46.088:INFO::main: Logging initialized #290ms
2015-02-23 09:24:46.222:INFO:oejs.Server:main: jetty-9.2.7.v20150116
and request it via curl ...
$ curl http://localhost:9090/props/props/foo.jetty.dir
[foo.jetty.dir] = more of the same
Related
Has anyone successfully got the HTTP/2 connector working in Tomcat9 on AIX (e.g. powerpc-ibm-aix7.2.5.0)?
I followed the instructions here to build the tcnative module (using tomcat-native-1.2.24-src that comes with Tomcat 9.0.37, APR 1.5.2, OpenSSL 1.0.2, IBM Java 1.8.0_261) i.e.
$ ./configure --with-apr=/opt/freeware/bin/apr-1-config --with-java-home=/app/java8_64/ --with-ssl=yes --prefix=/app/tomcat
followed by
make && make install
This creates the expected entries in /app/tomcat/lib, i.e.
-rw-r--r-- 1 usrxxx grpxxxx 3440287 Mar 03 16:47 libtcnative-1.a
-rwxr-xr-x 1 usrxxx grpxxxx 1057 Mar 03 16:47 libtcnative-1.la
lrwxrwxrwx 1 usrxxx grpxxxx 23 Mar 03 16:47 libtcnative-1.so -> libtcnative-1.so.0.2.24
lrwxrwxrwx 1 usrxxx grpxxxx 23 Mar 03 16:47 libtcnative-1.so.0 -> libtcnative-1.so.0.2.24
-rwxr-xr-x 1 usrxxx grpxxxx 1372146 Mar 03 16:47 libtcnative-1.so.0.2.24
but when Tomcat starts I get
04-Mar-2021 15:30:00.752 WARNING [main] org.apache.catalina.core.AprLifecycleListener.init The Apache Tomcat Native library failed to load. The error reported was [tcnative-1 (Not found in java.library.path)]
java.lang.UnsatisfiedLinkError: tcnative-1 (Not found in java.library.path)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1462)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:1414)
at java.lang.System.loadLibrary(System.java:584)
at org.apache.tomcat.jni.Library.<init>(Library.java:69)
at org.apache.tomcat.jni.Library.initialize(Library.java:206)
at org.apache.catalina.core.AprLifecycleListener.init(AprLifecycleListener.java:198)
...
04-Mar-2021 15:30:01.096 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.library.path=/app/java8_64/jre/lib/ppc64/compressedrefs:/app/java8_64/jre/lib/ppc64:/app/java8_64/jre/lib/ppc64/j9vm:/app/java8_64/jre/lib/ppc64:/app/java8_64/jre/../lib/ppc64:/app/java8_64/jre/lib/icc:/opt/freeware/lib:/opt/freeware/lib64:/usr/lib:/usr/lib64:/app/tomcat/lib:/usr/lib64:/usr/lib
...
04-Mar-2021 15:30:02.233 SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector[org.apache.coyote.http11.Http11AprProtocol-8443]] org.apache.catalina.LifecycleException: The configured protocol [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library which is not available
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1024)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.core.StandardService.initInternal(StandardService.java:533)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1057)
Edit - based on suggestions from Piotr and Lorinczy:
Tried adding tcnative-1.so as a symlink - same error
Copied libtcnative-1.* to the bin folder. Still failing but new error (progress!?). Possible 32bit v 64bit issue?
09-Mar-2021 10:10:07.116 WARNING [main] org.apache.catalina.core.AprLifecycleListener.init The Apache Tomcat Native library failed to load. The error reported was [/app/apache-tomcat-9.0.37/bin/libtcnative-1.a ( 0509-022 Cannot load module /app/apache-tomcat-9.0.37/bin/libtcnative-1.a.
0509-026 System error: Cannot run a file that does not have a valid format.)]
java.lang.UnsatisfiedLinkError: /app/apache-tomcat-9.0.37/bin/libtcnative-1.a ( 0509-022 Cannot load module /app/apache-tomcat-9.0.37/bin/libtcnative-1.a.
0509-026 System error: Cannot run a file that does not have a valid format.)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1462)
...
All the dependencies seem to be available
$ldd libtcnative-1.so.0.2.24
libtcnative-1.so.0.2.24 needs:
/usr/lib/libssl.so
/usr/lib/libcrypto.so
/opt/freeware/lib/libapr-1.so
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/lib/libc.a(shr.o)
/opt/freeware/lib/libgcc_s.a(shr.o)
/usr/lib/libcrypto.a(libcrypto.so.1.0.2)
/unix
/usr/lib/libpthreads.a(shr_comm.o)
/usr/lib/libcrypt.a(shr.o)
but the dump command seems to support the 32 v 64 bit theory:
$ dump -H -X64 libtcnative-1.so.0.2.24
libtcnative-1.so.0.2.24:
dump: libtcnative-1.so.0.2.24: 0654-108 file is not valid in the current object file mode.
Use the -X option to specify the desired object mode.
$ dump -H -X32 libtcnative-1.so.0.2.24
libtcnative-1.so.0.2.24:
***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00000364 0x00000771 0x00000084
#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000007 0x0000aacc 0x00006406 0x0000ab50
***Import File Strings***
INDEX PATH BASE MEMBER
0 /opt/freeware/lib:/usr/lib:/lib
1 libssl.so
2 libcrypto.so
3 libapr-1.so
4 libpthread.a shr_xpg5.o
5 libc.a shr.o
6 libgcc_s.a shr.o
It looks like only the 32-bit version of APR is currently available on the server also. I will update once I can get the 64-bit version installed.
Further Updates
The commands I am trying now are:
$ export CFLAGS=-maix64
$ export OBJECT_MODE=64
$ ./configure --with-apr=/opt/freeware/bin/apr-1-config_64 --with-java-home=/app/java8_64/ --with-ssl=/usr/include/openssl --prefix=/app/tomcat
$ make && make install
No errors but same outcome however. This doesn't seem to build a 64 bit version of the tomcat native module (if that is the issue).
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.
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.
I am trying to deploy Tomcat on Openshift with
$oc new-app tomcat:latest
and when I do
$oc get pods
I am getting
NAME READY *STATUS* RESTARTS *AGE*
tomcat-1-9j5qx 0/1 *CrashLoopBackOff* 16 *1h*
when I check logs with $oc logs tomcat-1-9j5qx i get
Feb 05, 2018 11:26:41 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/local/tomcat/conf/server.xml]
Feb 05, 2018 11:26:41 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/local/tomcat/conf/server.xml]
Feb 05, 2018 11:26:41 AM org.apache.catalina.startup.Catalina start
SEVERE: Cannot start server. Server instance is not configured.
not sure what I should be doing to get rid of this CrashLoopBackOff
By default, OpenShift uses a random non-root uid to run pods, while this /usr/local/tomcat/conf/servers only allows root to read it. Run this command to allow OpenShift to run pods with any uid:
oc adm policy add-scc-to-user anyuid -z default
This change in policy can only be done by someone who is cluster admin. It cannot be done by a normal user, or even a project admin.
Because you are granting the right to run things as root, even if only in a container, it is better to create a separate service account to run just the applications requiring the extra privileges, and not use the default service account.
For example:
$ oc create serviceaccount supremo
serviceaccount "supremo" created
$ oc adm policy add-scc-to-user anyuid -z supremo
$ oc patch dc/tomcat --patch '{"spec":{"template":{"spec":{"serviceAccountName": "supremo"}}}}'
deploymentconfig "tomcat" patched
You should also only do this for third party images you pull down which you trust. Do not give arbitrary images the ability to run as root.
I installed neo4j 1.8.2 on opensuse 12.2/64. To do so I had to add the JAVA_HOME path in the /etc/profile file as:
export JAVA_HOME=/opt/java/64/jdk1.7.0_21/jre/:
export PATH=$PATH:/opt/java/64/jdk1.7.0_21/jre/bin/;
Now when I try to check the server status I get the following error
>service neo4j-service status
neo4j-service.service - LSB: The Neo4J graph database server. See http://neo4j.org
Loaded: loaded (/etc/init.d/neo4j-service)
Active: failed (Result: exit-code) since Fri, 26 Apr 2013 17:13:56 +0200; 10s ago
Process: 7234 ExecStart=/etc/init.d/neo4j-service start (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/neo4j-service.service
Apr 26 17:13:56 linux-wwcz neo4j-service[7234]: which: no java in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/...bin)
Apr 26 17:13:56 linux-wwcz neo4j-service[7234]: Error: JAVA_HOME is not defined correctly.
Apr 26 17:13:56 linux-wwcz neo4j-service[7234]: We cannot execute
It's quite puzzling considering neo4j-service links to ./bin/neo4j, namely the file used at installation time with
./bin/neo4j install
Some ideas on what is going on here?
Thanks
SOLVED
Actually I was using jdk 7 instead of jdk 6
EDIT 2
According to the official neo4j page one runs the server using neo4j start. But I got into troubles when trying to run service neo4j start/status/stop as suggested in the Installing Neo4j in Linux how-to.
Try changing them to this:
export JAVA_HOME=/opt/java/64/jdk1.7.0_21/:
export PATH=$PATH:/opt/java/64/jdk1.7.0_21/bin/;
Not exactly for the question, but I reached here because I also though Neo4j could not find the environment variable JAVA_HOME when
sudo neo4j start
My problem was that OS reset environment variables when using sudo.
sudo -E neo4j start
solved my problem.