主题

为什么我的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目录，这里是play中的大多数主要元素所在的位置。这里有一件工艺品。该文件为Artifactory设置了一些默认值。它添加了JFrog和Tomcat主变量
出口JF_PRODUCT_HOME = / opt / jfrog / artifactory
出口TOMCAT_HOME = $ JF_PRODUCT_HOME / app / artifactory / tomcat

并设置了很多默认的JAVA_OPTS，包括“- doorg .apache.tomcat.util.buf. udecoder . zip”。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，您将使用“artifactory.sh开始”。在脚本中，在启动Artifactory的init()函数之前，它运行一些设置步骤并设置一些环境变量。正如您在下面的代码片段中看到的，调用了artifact .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(在artificial .default中设置)来启动Tomcat和Catalina。

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

artifactory.sh和artifactoryManage.sh之间的主要区别是，artifactory.sh直接调用Tomcat和artifactorymanage .default文件，但是artifactoryManage.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 && \ . cp ${serviceFiles}/setenv.sh ${TOMCAT_HOME

默认从$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
echo“最大打开文件数:$(ulimit -n)”
echo "Using JF_PRODUCT_HOME: ${JF_PRODUCT_HOME}"
echo "Using 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”

如您所见，它调用了artifact .default文件，将CATALINA_OPTS (artifactory运行在其上的tomcat webapp)设置为使用JAVA_OPTS集，并为webapp设置CATALINA_HOME。如果我们查看脚本，接下来的部分会变得有点复杂，但实际上，artifactoryManage.sh调用tomcat启动脚本，该脚本调用catalina.sh脚本，该脚本使用CATALINA_HOME查找setenv.sh并运行该文件。

总之，通过installService.sh命令，setenv.sh被移动到Tomcat主目录，并使用artifactoryManage.sh。这个脚本调用Tomcat的启动脚本，该脚本调用catalina.sh，该脚本使用一些环境变量调用setenv.sh。与artificial .sh脚本不同，这个脚本更多地依赖于调用其他脚本。

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

决议

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