CentOS 上的人工环境变量答案

【问题标题】：Artifactory environment variables on CentOSCentOS 上的人工环境变量
【发布时间】：2015-09-11 16:26:27
【问题描述】：

我要疯了。

/usr/lib/jvm/

有

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

昨晚在最不幸的时候，神器显然正在使用的#65的内容消失了。爪哇消失了。也许它已经消失了，但是新的 Linux 人员正在“升级”机器，所以这很可疑。

现在，问题是 Artifactory 不能忘记版本 65。

如果我输入env 或set，我们就成功了。没有提到v65。但人工制品生活在它自己的世界里。

[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 和set 显示

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 也是正确的。 ls -l显示

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

所以它指向正确的地方。神器用户到底是从哪里得到65的？如果我尝试su artifactory，我去bash-4.1$表明artifactory不是传统意义上的用户，但即便如此，env和set都是正确的。

我终于设法通过妥协让它发挥作用。

/opt/jfrog/artifactory/bin

我编辑了 artifactory.default 并将我的导出 JAVA_HOME 放在那里，并从该文件夹而不是作为服务启动了 artifactory。这将一直持续到 Linux 团队下一次搞砸我的服务器。

但是有人知道我怎样才能让它作为服务运行吗？

【问题讨论】：

标签： java linux tomcat environment-variables artifactory

【解决方案1】：

查看 /etc/init.d/artifactory，它是在您调用“服务工件...”时运行的脚本 - 看起来其中的某些东西（可能是另一个来源的脚本）正在设置JRE_HOME 到旧版本。

你也可以试试

sudo su - artifactory; env | grep JRE

确保工件用户的环境没有将 JRE_HOME 设置为旧版本。

【讨论】：

/etc/init.d/artifactory 中没有任何可疑之处。我确实在 /etc/profile.d/java.sh 下找到了设置 JAVA_HOME 和 JRE_HOME 的违规位置。现在，当我尝试启动服务时，我得到了正确的 JRE_HOME，但是“只读连接、用户或数据库不允许 SQL 数据更改”。唔。有什么想法吗？
听起来您配置 Artifactory 使用的 MySQL 用户没有 Artifactory 数据库的写入权限。查看jfrog.com/confluence/display/RTF/MySQL 并确保您已运行该页面上提到的 GRANT 命令。

【解决方案2】：

之后我遇到了类似的问题。安装了 Artifactory 5.3.2，几个月后在我的 Linux 服务器上运行了 yum 更新。我看到了消息：“错误工件 tomcat 服务器没有在 60 秒内启动” 这个问题是在我运行 yum 更新后开始的。该更新影响了我的 java 版本，如下所述。

验证错误日志

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

--> /opt/jfrog/artifactory/tomcat/bin/catalina.sh：第 433 行：/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64 /bin/java: 没有这样的文件或目录

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/

重启catalina

./catalina.sh

artifactory 将重新启动并且应该显示更新的 JRE_HOME

【讨论】：