Tomcat 9 不再使用 systemctl 启动，而是手动启动答案

【问题标题】：Tomcat 9 no longer starting using systemctl but will start manuallyTomcat 9 不再使用 systemctl 启动，而是手动启动
【发布时间】：2025-05-02 21:10:01
【问题描述】：

一直在研究这个问题。我查看了有关此问题的多篇文章。这是最接近的：

Tomcat 8 on CentOS 7 does not start as service (but it starts manually ....)

不同之处在于我运行的是 Tomcat 9.0.33。详情如下：

java version "1.8.0_121"\
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)\
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)\

Tomcat 9.0.33

NAME="CentOS Linux"\
VERSION="7 (Core)"\
ID="centos"\
ID_LIKE="rhel fedora"\
VERSION_ID="7"\
PRETTY_NAME="CentOS Linux 7 (Core)"\
ANSI_COLOR="0;31"\
CPE_NAME="cpe:/o:centos:centos:7"\
HOME_URL="https://www.centos.org/"\
BUG_REPORT_URL="https://bugs.centos.org/"\

CENTOS_MANTISBT_PROJECT="CentOS-7"\
CENTOS_MANTISBT_PROJECT_VERSION="7"\
REDHAT_SUPPORT_PRODUCT="centos"\
REDHAT_SUPPORT_PRODUCT_VERSION="7"\

附带说明，直到最近，一切都正常开始，没有任何问题。据我所知，环境没有任何重大变化。但是，当我最近运行“systemctl restart”命令时，启动开始失败。有 5 个 Tomcat 9.0.33 实例在不同的端口和路径上运行，并且没有改变。我还没有重新启动两个实例（怕它们不会启动），另外三个完全不会启动。详情如下：

Systemd unit file for tomcat\
[Unit]\
Description=Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
After=syslog.target network.target

[Service]\
Type=forking

Environment=JAVA_HOME=/opt/jdk1.8.0_121/jre\
Environment=CATALINA_PID=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/temp/tomcat.pid\
Environment=CATALINA_HOME=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment=CATALINA_BASE=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33\
Environment='CATALINA_OPTS=-Xms1024m -Xmx2048m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:SurvivorRatio=20 -XX:ParallelGCThreads=8 -server -Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n'\
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom -Duser.timezone=GMT -Dfile.encoding=UTF-8'

ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh\
ExecStop=/bin/kill -15 $MAINPID

User=tomcat\
Group=tomcat\
UMask=0007

[Install]\
WantedBy=multi-user.target\

运行 systemctl start liferayuat 时的结果

● liferayuat.service - Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT\
   Loaded: loaded (/etc/systemd/system/liferayuat.service; enabled; vendor preset: disabled)\
   Active: failed (Result: exit-code) since Sat 2020-12-05 08:44:08 CST; 3s ago\
  Process: 10891 ExecStop=/bin/kill -15 $MAINPID (code=exited, status=1/FAILURE)\
  Process: 10851 ExecStart=/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh \(code=exited, status=0/SUCCESS)\
 Main PID: 10861 (code=exited, status=0/SUCCESS)

Dec 05 08:44:08  systemd[1]: Starting Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT...\
Dec 05 08:44:08  startup.sh[10851]: Existing PID file found during start.\
Dec 05 08:44:08  startup.sh[10851]: Removing/clearing stale PID file.\
Dec 05 08:44:08  startup.sh[10851]: Tomcat started.\
Dec 05 08:44:08  systemd[1]: Started Apache Tomcat Web Application Container in Liferay 7.32 TEST for UAT.\
Dec 05 08:44:08  systemd[1]: liferayuat.service: control process exited, code=exited status=1\
Dec 05 08:44:08  systemd[1]: Unit liferayuat.service entered failed state.\
Dec 05 08:44:08  systemd[1]: liferayuat.service failed.

然后是 catalina.out 中唯一的东西：

Listening for transport dt_socket at address: 5000\
java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina\
        at java.net.URLClassLoader.findClass(URLClassLoader.java:381)\
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)\
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)\
        at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:261)\
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:443)\

所以，当我使用 systemctl start 启动实例时，它会失败。但是如果我运行这个命令（以 root 身份...）那么它将启动：

/opt/liferay/uatapi/liferay-ce-portal-7.3.2-ga3/tomcat-9.0.33/bin/startup.sh

如果我运行完整的命令 AS tomcat，它不会以相同的错误开始。因此，问题似乎是权限。 tomcat 用户和组是所有文件和文件夹的所有者。但是，不知何故，tomcat 用户要么没有权限，要么路径被抬高，因此无法找到类文件。我遵循了我上面引用的文章中的建议，但所做的更改没有影响。

我偶然发现了一篇关于 SELINX 的文章，该文章似乎指出了那里的一个问题。这是 SELINUX 设置：

SELinux 状态：启用
SELinuxfs 挂载：/sys/fs/selinux
SELinux 根目录：/etc/selinux
加载的策略名称：targeted
当前模式：许可
配置文件中的模式：permissive
策略 MLS 状态：启用
策略拒绝未知状态：允许
最大内核策略版本：31\

保持实例运行的解决方法只是手动启动它们，但是是什么导致 systemctl start 不起作用？我怀疑权限，但我肯定不明白为什么，因为一切都归 tomcat:tomcat 所有

【问题讨论】：

为了可能消除 SELinux 的原因，您可以暂时禁用 SELinux 并查看通过 systemctl 启动是否有效？
谢谢吉姆...我也看到了这个建议。 sudo setenforce 0 不会改变状态。这些实例的 Centos VM 也运行在生产实例的主机上，所以如果需要的话，我无法退回服务器
那么您需要在可以进行真正故障排除的地方重现问题。
再次感谢。不同的 VM 可能有不同的设置。我当然可以建立一个 CentOS 7 虚拟机，看看我是否可以通过启用和禁用 SELINUX 来模拟这个问题。这不能解释为什么它突然改变，但可能指向一个可能的原因。所以你认为 SELINUX 是这里的根本问题？
我不知道。如果您想排除在生产系统上无法解决的问题，则必须在测试系统上运行它并更改 SELinux 之类的东西，直到您弄清楚是什么影响了它。

标签： java tomcat9 systemctl

【解决方案1】：

所以，这和大多数“谜团”一样都是自己造成的。我仍然无法解释在查看实例之间的 SELinux 上下文时看到的一些差异，但真正的原因是微妙的（对我而言）。 {tomcat root}/lib 和 {tomcat root}/lib/ext 的权限没有执行权限。这可能是由于最近添加了一个 jar，然后需要由所有者和权限更新。无论如何，最初的问题导致了许多尝试和错误的尝试来修复它，这使事情变得更加复杂。

我通过对工作实例和非工作实例进行逐个文件夹、逐个文件的比较来发现解决方案。显然，新 jar 和所有者/权限更改已应用于除生产版本之外的所有版本。

感谢您的建议。

【讨论】：