将 Artifactory 升级到最新版本时 CATALINA_PID 和 ARTIFACTORY_PID 的问题 [英] Problems with CATALINA_PID and ARTIFACTORY_PID while upgrading Artifactory to the latest version

问题描述

在将我的 Artifactory 服务器(免费 OSS 版本)从 5.2.0 版本升级到最新的 5.4.5 时，我遇到了 ARTIFACTORY_PID 问题.从5.3.2迁移到5.4.0后，Artifactory服务器不想再开始抱怨

While upgrading my Artifactory server (free OSS version) from the version 5.2.0 to the latest 5.4.5, I was hit by an ARTIFACTORY_PID problem. After migrating from 5.3.2 to 5.4.0, the Artifactory server did not want to start anymore complaining about

PID 文件/var/opt/jfrog/run/artifactory.pid 在启动后不可读(还?).

PID file /var/opt/jfrog/run/artifactory.pid not readable (yet?) after start.

我发现解决它的唯一方法是从 tomcat 的 setenv.sh 中删除 export CATALINA_PID=$ARTIFACTORY_PID 行.

I found the only way around it is to remove the line export CATALINA_PID=$ARTIFACTORY_PID from the setenv.sh of the tomcat.

请注意，从 5.2.0 升级到 5.3.2 很顺利.

Note that upgrade from 5.2.0 to 5.3.2 went smoothly.

但是，从 5.4.0 升级到最新的 5.4.5 后，此技巧不再起作用.现在我收到一个错误:

However, after upgrading from 5.4.0 to the latest 5.4.5 this trick does not work anymore. Now I get an error:

artifactory.service 的作业失败，因为超出了配置的资源限制.详情参见systemctl status artifactory.service"和journalctl -xe".

Job for artifactory.service failed because a configured resource limit was exceeded. See "systemctl status artifactory.service" and "journalctl -xe" for details.

当执行service artifactory status 时，我得到:

● artifactory.service - Setup Systemd script for Artifactory in Tomcat Servlet Engine
   Loaded: loaded (/usr/lib/systemd/system/artifactory.service; enabled; vendor preset: disabled)
   Active: activating (auto-restart) (Result: resources) since Tue 2017-07-25 09:40:10 CEST; 4s ago
  Process: 31912 ExecStart=/opt/jfrog/artifactory/bin/artifactoryManage.sh start (code=exited, status=0/SUCCESS)

Jul 25 09:40:10 linux systemd[1]: Failed to start Setup Systemd script for Artifactory in Tomcat Servlet Engine.
Jul 25 09:40:10 linux systemd[1]: Unit artifactory.service entered failed state.
Jul 25 09:40:10 linux systemd[1]: artifactory.service failed.

事实上，Artifactory 现在正在运行，显示版本为 5.4.5，但我对上述所有错误并不满意.

In fact Artifactory is now running showing version 5.4.5, but I am not happy about all those errors above.

另外，我有点不明白 CATALINA_PID 和/或 ARTIFACTORY_PID 的用途.为什么tomcat会因为这个文件启动失败?权限有什么问题?我想我之前没有做额外的动作.

Plus I am a bit failing to understand the purpose of CATALINA_PID and/or ARTIFACTORY_PID. Why the tomcat was failing on the startup because of this file? What was wrong with the permissions? I think I did no extra actions before.

唯一的区别是之前从官方下载的rpm安装.但现在使用官方远程 yum 存储库.

The only difference that before it was installed from an official downloaded rpm. But now using an official remote yum repo.

如果我尝试创建一个空的/var/opt/jfrog/run/artifactory.pid 文件，当 Artifactory 正在运行时，它会被删除.谁在删除这个文件，为什么?这是标准的tomcat行为吗?

If I try to create an empty /var/opt/jfrog/run/artifactory.pid file, while Artifactory is running, it gets deleted. Who is deleting this file and why? Is it a standard tomcat behavior?

操作系统:CentOS 7，最新.

OS: CentOS 7, up to date.

推荐答案

在我的情况下(在慢速虚拟机中)来自命令 artifactoryManage.sh start 的错误消息是:

In my case (in a slow virtual machine) the error message from the command artifactoryManage.sh start was:

错误:Artifactory Tomcat 服务器未在 60 秒内启动.请检查日志

ERROR: Artifactory Tomcat server did not start in 60 seconds. Please check the logs

日志文件表明唯一的问题是速度慢(/var/opt/jfrog/artifactory/logs/artifactory.log):

The log file told that the only problem was slowness (/var/opt/jfrog/artifactory/logs/artifactory.log):

### Artifactory 成功启动(64.802 秒)###

### Artifactory successfully started (64.802 seconds) ###

通过向/etc/systemd/system/artifactory.service 中的服务定义添加更长的超时解决了该问题:

The problem was solved by adding a longer timeout to the service definition at /etc/systemd/system/artifactory.service:

[Service]
Environment=START_TMO=120

编辑服务定义后，如您所知，需要systemctl daemon-reload.

After editing the service definition, as you know, systemctl daemon-reload was needed.

这篇关于将 Artifactory 升级到最新版本时 CATALINA_PID 和 ARTIFACTORY_PID 的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！