主题

为什么我的Linux Archive服务升级后安装失败/降级?

影响版本

所有7。xlinux archive installs that are installed as a service. This means you use systemd (systemctl/service) to control the application, and had run the $ARTIFACTORY_HOME/app/bin/installService.sh事先。

描述

请注意，所有提到的脚本(除了setenv.sh脚本)在$ARTIFACTORY_HOME/app/bin/

此问题可能导致各种症状，从无法正确解析编码字符(例如在npm包中编码为%2f的' / ')到tomcat日志不显示，再到实例未接受自定义java选项(例如内存增加)。这背后的原因是因为应用于实例的大多数JAVA_OPTS都丢失了。这个解释有点冗长，但如果你正在寻找一个解决方案，你可以在页面底部找到一个简单而简短的解决方案。

那么为什么会发生这种情况呢?为了理解这一点，我们需要转到$ARTIFACTORY_HOME/app/bin目录，大多数主要元素都在这里运行。这里有一个人工制品。default文件，它为Artifactory设置了一些默认值。它添加了JFrog和Tomcat主变量
出口JF_PRODUCT_HOME = / opt / jfrog / artifactory
出口TOMCAT_HOME = $ JF_PRODUCT_HOME / app / artifactory / tomcat

并设置了许多默认的JAVA_OPTS，包括“- dog .apache.tomcat.util.buf. udecoder . conf”。ALLOW_ENCODED_SLASH "这是一些npm请求所必需的。这是一个小而简单的文件，用于为Artifactory设置默认值。在7。xthe systemYaml has an extraJavaOpts: line to set your own Java Options (such as increasing the -Xmx value), and on startup the application takes in the JAVA_OPTS from this file and appends the extraJavaOpts to apply them all.

如果您通过脚本启动工件，您将使用“artifactory.sh开始”。在脚本中，在启动Artifactory的init()函数之前，它运行了几个设置步骤并设置了一些环境变量。在下面的代码片段中可以看到，调用artifactory.default文件来设置该文件中的所有变量
artDefaultFile = " $ {ARTIFACTORY_BIN_FOLDER} / artifactory.default”

。${artDefaultFile} || errorArtHome "错误:$artDefaultFile不存在或不可执行"
PRODUCT_ETC = $ {JF_PRODUCT_HOME} / var /等
ART_ETC = PRODUCT_ETC / ARTIFACTORY_NAME美元
ACCESS_ETC = PRODUCT_ETC / ACCESS_NAME美元
REPLICATOR_ETC = PRODUCT_ETC / REPLICATOR_NAME美元

初始化

然后脚本调用TOMCAT_HOME(在artifactory.default中设置)来启动Tomcat和Catalina。

所以到目前为止它非常简单，Artifactory脚本->调用文件来设置环境->设置Tomcat ->启动Artifactory。现在的问题是，当您调用installService.sh脚本来设置服务时，它不会使用artifactory.sh。我们有一个不同的文件artifactorymanagement .sh，它与systemctl/systemd过程兼容。所以如果我运行installService.sh文件，它会创建一个/lib/systemd/system/artifactory。服务文件(可能因操作系统而异，您可以运行systemctl状态人工程序来查看文件位置)。查看该文件，我们看到" start "和" stop "命令使用" artifactoryManage.sh start/stop "
ExecStart = / opt / jfrog / artifactory / app / bin / artifactoryManage.sh开始
ExecStop = / opt / jfrog / artifactory / app / bin / artifactoryManage.sh停止

artifactorymanagement .sh和artifactorymanagement .sh之间的主要区别在于，artifactorysh直接调用Tomcat和artifactorydefault文件，而artifactorymanagement .sh使用一个特定的文件来调用它们。这个文件就是setenv.sh文件(更多信息请访问tomcat https://tomcat.apache.org/tomcat-7.0-doc/RUNNING.txt)。sh文件将文件从默认位置复制到预期的TOMCAT_HOME位置，如下所示
cp ${serviceFiles}/setenv.sh ${TOMCAT_HOME}/bin/setenv.sh && \

默认从$ARTIFACTORY_HOME/app/misc/service/setenv.sh到$ARTIFACTORY_HOME/app/artifactory/tomcat/bin/setenv.sh。如果您检查setenv.sh文件，它看起来是这样的
#！/bin/bash
。$ {JF_PRODUCT_HOME} / app / bin / artifactory.default
最大打开文件数:$(ulimit -n)
使用JF_PRODUCT_HOME: ${JF_PRODUCT_HOME}"
使用JF_ARTIFACTORY_PID: $JF_ARTIFACTORY_PID

出口CATALINA_TMPDIR = $ {JF_PRODUCT_HOME} / var /工作/ artifactory / tomcat / temp
export CATALINA_OPTS="$CATALINA_OPTS $JAVA_OPTIONS -Djruby.bytecode.version=1.8"
出口CATALINA_HOME = " $ TOMCAT_HOME”

如您所见，它调用artifactory.default文件，设置CATALINA_OPTS(运行artifactory的tomcat web应用程序)使用JAVA_OPTS集，并为web应用程序设置CATALINA_HOME。如果我们查看脚本，下一部分会变得有点复杂，但本质上是artifactoryManage.sh调用tomcat启动脚本，该脚本调用catalina.sh脚本，该脚本使用CATALINA_HOME查找setenv.sh并运行该文件。

总而言之，使用installService.sh命令将setenv.sh移动到Tomcat主目录，并使用artifactorymanagement .sh。该脚本调用Tomcat的启动脚本，该脚本调用catalina.sh，后者使用一些环境变量来调用setenv.sh。与artifactory.sh脚本不同，这个脚本更多地依赖于调用其他脚本。

问题就在这里出现了。当您为Linux Archive实例运行升级时，您将替换完整的/app/目录(以更新该目录中的二进制文件)。这样做的一个副作用是，setenv.sh脚本不再在Tomcat主目录中，它只是在那里，因为我们运行了installService.sh。这意味着当我们运行systemctl start artifactory时，它无法设置很多设置周围环境的环境变量，因此它以有限数量的硬编码默认值启动(没有artifactory.default变量，没有catalina_home等)。在某些情况下，由于默认资源较低，这甚至可能导致启动失败，而在其他情况下，您会看到由于2022世界杯阿根廷预选赛赛程其他症状导致的降级和失败。

决议

对这个问题的解释很长，但解决办法却相当简单。我们所需要做的就是将setenv.sh恢复到tomcat主位置，这样我们就可以再次运行installService.sh。这样做之后，实例就可以启动并使用适当的资源和变量运行了。2022世界杯阿根廷预选赛赛程作为将来升级的注意事项，任何时候升级linux存档安装时，都应该在启动之前运行installService.sh。