CentOS上的人工环境变量

Question

I'm going mad.

/usr/lib/jvm/

has

java-1.7.0-openjdk-1.7.0.65.x86_64
java-1.7.0-openjdk-1.7.0.79.x86_64

Last night at the most unfortunate possible time, the contents of #65, which artifactory was apparently using, disappeared. Java disappeared. Maybe it was already gone, but the new Linux guys were 'upgrading' the machine, so it's suspicious.

Now, the issue is that artifactory cannot forget about version 65.

If I type in env or set , we're golden. No mention of v65. But artifactory lives in its own world.

[root@me]# service artifactory check
Checking arguments to Artifactory:
ARTIFACTORY_HOME     =  /var/opt/jfrog/artifactory
ARTIFACTORY_USER     =  artifactory
TOMCAT_HOME          =  /opt/jfrog/artifactory/tomcat
ARTIFACTORY_PID      =  /var/opt/jfrog/run/artifactory.pid
JAVA_HOME            =
JAVA_OPTIONS         =  -server -Xms512m -Xmx2g -Xss256k -XX:PermSize=128m -XX:MaxPermSize=256m -XX:+UseG1GC

[root@me]# service artifactory start
Starting Artifactory tomcat as user artifactory...
Max number of open files: 32000
Using ARTIFACTORY_HOME: /var/opt/jfrog/artifactory
Using ARTIFACTORY_PID: /var/opt/jfrog/run/artifactory.pid
Using CATALINA_BASE:   /opt/jfrog/artifactory/tomcat
Using CATALINA_HOME:   /opt/jfrog/artifactory/tomcat
Using CATALINA_TMPDIR: /opt/jfrog/artifactory/tomcat/temp
Using JRE_HOME:        /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65.x86_64/jre
Using CLASSPATH:       /opt/jfrog/artifactory/tomcat/bin/bootstrap.jar:/opt/jfrog/artifactory/tomcat/bin/tomcat-juli.jar
Using CATALINA_PID:    /var/opt/jfrog/run/artifactory.pid

env and set shows

JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk.x86_64
JRE_HOME=/usr/lib/jvm/java-1.7.0-openjdk.x86_64/jre

PATH is correct too. ls -l shows

lrwxrwxrwx  1 root root   34 Jun 24 22:38 java-1.7.0-openjdk.x86_64 -> java-1.7.0-openjdk-1.7.0.79.x86_64

So it's pointing to the right place. Where in the hell is the artifactory user getting 65 from? If I try su artifactory , i go to bash-4.1$ indicating that artifactory isn't a user in the traditional sense, but even so, env and set are correct.

I finally managed to get it working by compromising.

/opt/jfrog/artifactory/bin

I edited artifactory.default and put my export JAVA_HOME in there, and started artifactory from that folder, instead of as a service. This will do until the next time the Linux team mess up my server.

But anyone know how I can get it running as a service?

Answer 1

Take a look in /etc/init.d/artifactory, which is the script that runs when you call "service artifactory ..." - it looks like something in there (possibly another script that is sourced in) is setting JRE_HOME to the old version.

You could also try

sudo su - artifactory; env | grep JRE

to make sure that the artifactory user's environment doesn't set JRE_HOME to the old version.

Answer 2

I had a similar issue after. Installed Artifactory 5.3.2 and months later ran a yum update on my Linux server. I saw the msg: "error artifactory tomcat server did not start in 60 seconds" The issue started after a I ran a yum update. The update impacted my version of java as noted below.

Verify Error Log

vi /var/opt/jfrog/artifactory/logs/catalina.out

--> /opt/jfrog/artifactory/tomcat/bin/catalina.sh: line 433: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64/bin/java: No such file or directory

vi /opt/jfrog/artifactory/tomcat/bin/catalina.sh
export JRE_HOME=/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64
export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64
cd /opt/jfrog/artifactory/tomcat/bin/

restart catalina

./catalina.sh

artifactory will restart and should show updated JRE_HOME