Tomcat开机自启全攻略：systemd、SysV脚本与rc.local实战-代码聚汇网

Tomcat开机自启全攻略：systemd、SysV脚本与rc.local实战

幸运小姐·2026-09-01·阅读 25 GEO检测（免费）

Tomcat开机自启systemdSysV init

|难度：普通|阅读约 49 分钟

1. 为什么Tomcat开机自启这么容易翻车

前两周有位做独立站的朋友半夜给我打电话，说站点突然打不开了。我远程上去一看，原因很朴素：机房那边服务器自动重启过一次，Tomcat没跟着起来，网站自然就挂了。这种问题在运维场景里实在太常见了，常见到很多人都默认它是"小事一桩"，结果真出事的时候，就是流量高峰、老板盯着的时刻。

先把这个话题聊透一点。Tomcat本身和Nginx、Redis这类由发行版官方仓库维护的服务不同，它没有像 apt install tomcat9 那样干净的"系统服务化管理"路径（就算有，版本也常常偏旧），主流做法还是下载二进制包解压到某个目录，然后靠 bin/startup.sh 或 bin/catalina.sh run 这种脚本手动启停。二进制包解压就意味着它天然不是一个"注册在系统里的服务"，系统开机时当然不会主动去管它。

Linux 的开机启动机制又分几个时代：老一点的 SysV init，后来 CentOS 7 / Ubuntu 16.04 全面转向 systemd，另外还有 /etc/rc.local 这种兜底方式。很多人照着网上的教程配完还是不行，大概率不是命令敲错，而是没搞明白这几种方式各自的前提条件和隐藏坑点。

这篇文章我把 Linux 下给 Tomcat 设置开机自启这件事一次讲透，按推荐度从高到低梳理三套方案：systemd 服务单元、SysV init 脚本、rc.local 兜底。每套都会讲清楚原理、步骤、坑点，最后再给一份"我自己的查错清单"。适合刚入门的 Linux 运维、经常折腾测试环境的开发，以及所有被"服务器重启后服务起不来"坑过的人。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 最推荐的方式：写一个 systemd 服务单元

如果你的系统是 CentOS 7+、RHEL、Rocky Linux、AlmaLinux、Ubuntu 16.04+、Debian 8+，几乎都是 systemd 管理的系统。现在新装服务器基本不会遇到 SysV init 了。systemd 是"开机启动 Tomcat"的第一推荐方案，没有之一。

2.1 先把 Tomcat 手动启动跑通

任何配置自启的前提，是你能先手动把 Tomcat 启动起来。这一步如果没跑通，后面配什么都是白搭。我见过太多同学跳过了手动验证直接去写 service 文件，最后失败了一层层查下来，发现是 Tomcat 自带的配置有问题。

假设你已经把 Tomcat 解压到了 /opt/tomcat 目录：

bash复制# 进入Tomcat安装目录
cd /opt/tomcat/bin

# 先看一下环境变量有没有JAVA_HOME
echo $JAVA_HOME

# 启动Tomcat（前台模式，方便观察日志）
./catalina.sh run

如果 JAVA_HOME 是空的，先手动指定一下再启动：

bash复制export JAVA_HOME=/usr/local/java/jdk-17
./catalina.sh run

看到类似 Server startup in [xxxx] milliseconds 的日志，说明手动启动没问题，可以 Ctrl+C 停掉，进入下一步。

很多老教程会让你直接执行 ./startup.sh，这个脚本本质上是调用了 catalina.sh start，它会做个 PID 文件记录并后台运行。但如果你配置 systemd，我建议先用 catalina.sh run 验证，因为前台模式能第一时间把启动错误暴露在终端里。

2.2 手写 tomcat.service 单元文件

systemd 的服务单元文件通常放在 /etc/systemd/system/ 目录下。命名规则是 服务名.service，比如 tomcat.service。

我的习惯是给 Tomcat 单独建一个专用系统用户，不用 root 去跑。理由后面再说，先看完整的单元文件：

ini复制[Unit]
Description=Apache Tomcat 9 Web Application Server
After=network.target
Wants=network.target

[Service]
Type=forking

# 指定运行用户和用户组
User=tomcat
Group=tomcat

# 从文件加载环境变量，避免在service文件里堆一堆export
EnvironmentFile=/etc/tomcat/tomcat.env

# 启动命令
ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

# PID文件，systemd靠它判断服务是否存活
PIDFile=/opt/tomcat/tomcat.pid

# 失败后自动重启
Restart=on-failure
RestartSec=5

# 安全加固，这个按需开
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

写完之后，加载并启动服务：

bash复制systemctl daemon-reload
systemctl enable tomcat
systemctl start tomcat
systemctl status tomcat

systemctl enable 做的事情，本质就是在 /etc/systemd/system/multi-user.target.wants/ 目录下创建一个软链接，让 systemd 在进入多用户模式时自动拉起这个服务。

2.3 单元文件里每个字段为什么这么写

初学者最容易犯的错，就是照抄网上配置，但不理解每个参数存在的意义。我逐项拆一下。

Type=forking 很关键。Tomcat 的 startup.sh 脚本启动后，主进程会 fork 出一个守护进程，然后父进程退出。这种"启动命令返回了，但实际服务还在后台跑"的行为模式，必须告诉 systemd："你等着，这个命令返回不代表服务起来，后面会有个 PID 文件告诉你真正的服务进程是谁。"所以必须配合 PIDFile 使用。如果你设成 Type=simple，systemd 会认为 startup.sh 退出时服务就停了，后面 Ctrl+C 或者服务重启时状态就会各种错乱。

EnvironmentFile=/etc/tomcat/tomcat.env 是我想重点强调的一个配置。很多人会问："我明明在 /etc/profile 里写了 JAVA_HOME，为什么 systemd 启动 Tomcat 时总是报 'The JAVA_HOME environment variable is not defined correctly'？"

原因是：systemd 启动服务时，并不会去加载 /etc/profile、~/.bashrc 这些 shell 配置文件。它在一个干净的环境里直接执行 ExecStart 命令。所以你在交互式终端里敲 echo $JAVA_HOME 有值，在 systemd 环境里可能什么都没有。

解决办法就是 EnvironmentFile。在 /etc/tomcat/tomcat.env 文件里写：

bash复制JAVA_HOME=/usr/local/java/jdk-17
CATALINA_HOME=/opt/tomcat
CATALINA_BASE=/opt/tomcat

注意，这个文件里不要写 export 前缀。systemd 的 EnvironmentFile 语法和 shell 的 export 语法不完全一样，它只识别 KEY=value 的格式。如果你从 /etc/profile 复制粘贴过来忘了删 export，会看到奇怪的解析报错。

User=tomcat 和 Group=tomcat 是为了安全。Tomcat 作为 Web 容器，理论上会运行来自互联网的请求，如果以 root 身份运行，一旦应用出现远程代码执行漏洞，攻击者直接就是 root 权限。单独建个低权限用户，即使被攻破，也只是 tomcat 用户权限。

建用户并授权目录：

bash复制useradd -r -s /sbin/nologin tomcat
chown -R tomcat:tomcat /opt/tomcat
chown -R tomcat:tomcat /etc/tomcat

After=network.target 表示要在网络服务启动后再拉起 Tomcat。这个不是绝对的，但很推荐。因为 Tomcat 启动时会尝试绑定端口，如果网络还没准备好，一些特殊环境可能会出现 bind 失败。Wants=network.target 和 After 配合，代表"我想在 network 起来之后再启动，但不是强制依赖"。

Restart=on-failure 是很有价值的一个配置。它表示当服务进程异常退出时，systemd 会自动把它拉起来。Tomcat 偶尔会因为 OOM 或者线程池耗尽等原因进程崩溃，有这一行至少能保证服务能自动恢复。RestartSec=5 是重启前的等待时间，防止故障时疯狂重启。

NoNewPrivileges=true 是安全加固项。它禁止服务进程通过 setuid、setgid 等方式提权。对 Tomcat 这种非特权服务来说，加上没有坏处。

2.4 多实例部署怎么办

如果一台机器上要跑多个 Tomcat 实例，比如一个跑后台管理，一个跑用户端 API，不要试图在一个 service 文件里启动两个。正确做法是复制单元文件，给不同实例不同的名字，比如：

ini复制# /etc/systemd/system/tomcat-admin.service
[Unit]
Description=Tomcat Admin Instance
After=network.target

[Service]
Type=forking
User=tomcat
Group=tomcat
EnvironmentFile=/etc/tomcat/admin.env
ExecStart=/opt/tomcat-admin/bin/startup.sh
ExecStop=/opt/tomcat-admin/bin/shutdown.sh
PIDFile=/opt/tomcat-admin/tomcat.pid
Restart=on-failure

[Install]
WantedBy=multi-user.target

每个实例独立目录、独立端口、独立环境变量文件。唯一需要注意的是，如果多个实例共用同一份 Tomcat 安装目录，CATALINA_BASE 必须指向各自独立的目录：

bash复制# admin.env
JAVA_HOME=/usr/local/java/jdk-17
CATALINA_HOME=/opt/tomcat-common
CATALINA_BASE=/opt/tomcat-admin

这样 startup.sh 会用 CATALINA_BASE 下的 conf、webapps、logs 目录来跑，而不是所有实例共享同一份开发配置。生产环境的多实例隔离我一直是这么处理的，宁可多占用一点磁盘，也不要把 conf 目录软链接来链接去。

3. 老系统怎么处理：SysV init 脚本

如果你的服务器还停留在 CentOS 6、Ubuntu 14.04 这样的老系统，或者公司内部强制要求用 SysV init 管理服务，那就得走 /etc/init.d/ 脚本这条路。

这方案现在的新机器用得越来越少了，但存量老机器还有不少。至少我手上还有几台跑着老业务的 CentOS 6 机器，没法随便升级，只能靠这套机制撑着。

3.1 init 脚本的基本骨架

SysV init 的核心，是在 /etc/init.d/ 下放一个可执行脚本，脚本里实现 start|stop|restart|status 这几个动作，然后通过 chkconfig 或 update-rc.d 注册开机启动项。

一个可以用的 Tomcat init 脚本长这样：

bash复制#!/bin/bash
#
# chkconfig: 2345 90 10
# description: Apache Tomcat Web Application Server
#

CATALINA_HOME=/opt/tomcat
JAVA_HOME=/usr/local/java/jdk-17
export JAVA_HOME CATALINA_HOME

start() {
    echo "Starting Tomcat..."
    su -s /bin/bash tomcat -c "$CATALINA_HOME/bin/startup.sh"
}

stop() {
    echo "Stopping Tomcat..."
    su -s /bin/bash tomcat -c "$CATALINA_HOME/bin/shutdown.sh"
}

status() {
    if [ -f "$CATALINA_HOME/tomcat.pid" ]; then
        PID=$(cat "$CATALINA_HOME/tomcat.pid")
        if kill -0 "$PID" >/dev/null 2>&1; then
            echo "Tomcat is running (PID $PID)"
        else
            echo "Tomcat is dead but pid file exists"
        fi
    else
        echo "Tomcat is not running"
    fi
}

case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    restart)
        stop
        sleep 2
        start
        ;;
    status)
        status
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
        ;;
esac
exit 0

保存为 /etc/init.d/tomcat，然后：

bash复制chmod +x /etc/init.d/tomcat

# CentOS/RHEL 系列用 chkconfig 注册
chkconfig --add tomcat
chkconfig --level 2345 tomcat on

# Debian/Ubuntu 系列用 update-rc.d
update-rc.d tomcat defaults

3.2 脚本头部的 chkconfig 注释到底有什么用

仔细看脚本头部，有一行被很多人忽略但极其关键的注释：

bash复制# chkconfig: 2345 90 10

这行的含义是：在运行级别 2、3、4、5 下启动该服务；启动优先级是 90，停止优先级是 10。SysV init 启动服务时会按照优先级从低到高执行，停止时从高到低执行。数字越小，启动越早。网络服务一般优先级在 10 到 20 之间，Tomcat 依赖网络，所以启动优先级不能太靠前，90 算是比较稳妥的位置。

如果没有这行注释，chkconfig --add tomcat 会报错：service tomcat does not support chkconfig。这是新手最容易踩的坑。

Debian 系的 update-rc.d 不读这行注释，它默认使用 update-rc.d defaults 里的默认优先级，效果类似。但如果你需要调整顺序，可以用：

bash复制update-rc.d tomcat start 90 2 3 4 5 . stop 10 0 1 6 .

3.3 为什么新系统不再推荐这种方案

SysV init 的问题在于：没有自动重启机制。脚本里写 start 就是启动，stop 就是停止，万一 Tomcat 进程崩了，不会有人自动把它拉起来（除非你在脚本里写 while 死循环轮询，那就太野了）。也没有日志统一管理、没有状态查询的标准化接口，status 动作是我们自己用 PID 文件模拟的，全靠脚本作者的自觉。

systemd 里的 Restart=on-failure 在 SysV 下要自己实现，太麻烦。所以还在用老系统的同学，如果短期没法升级，我建议至少配个外部监控脚本，定时探测 Tomcat 的 8080 端口，不通就自动重启。

4. 兜底方案：rc.local 里直接一行命令

最后介绍一个简单粗暴但依然有效的方案：改 /etc/rc.local。

4.1 rc.local 的原理

很多教程告诉你"编辑 /etc/rc.local，加一行启动命令就行了"，但没告诉你它为什么能生效。实际上，rc.local 在 systemd 系统上仍然是一个服务单元，叫 rc-local.service。

bash复制systemctl status rc-local

如果这个服务没起来，rc.local 里的命令就不会执行。Ubuntu 18.04 之后尤其常见。你可能配置了半天，reboot 后发现什么都没发生，检查一下这个服务状态通常能发现问题。

如果 rc-local.service 处于 failed 状态，或者根本不存在，手动创建一下：

ini复制[Unit]
Description=/etc/rc.local Compatibility
ConditionFileIsExecutable=/etc/rc.local

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

然后执行：

bash复制systemctl enable rc-local
systemctl start rc-local

CentOS 7 系统上，/etc/rc.local 通常是 /etc/rc.d/rc.local 的软链接，需要确认它自带可执行权限：

bash复制chmod +x /etc/rc.d/rc.local

这是一个非常隐蔽的坑：很多发行版默认把 /etc/rc.local 的可执行权限去掉了。你明明在里面写好了启动命令，结果重启后什么都没执行，检查半天发现权限位少了个 x。

在 /etc/rc.local 里加一行启动 Tomcat：

bash复制#!/bin/bash
su -s /bin/bash tomcat -c "/opt/tomcat/bin/startup.sh" >> /opt/tomcat/logs/rc-local.log 2>&1

4.2 rc.local 适合哪些场景

我个人对 rc.local 的态度是：能用，但别当主力方案。它适合的是这些情况：

临时服务器、实验环境、容器场景里快速拉起服务
不想为了一个小服务专门写 systemd 单元的场合
系统特别老或者特别精简，没有 systemd，也没有标准 init 脚本

但它有几个明显的短板：

第一，没有依赖管理。rc.local 里的命令是在系统启动的后期执行的，但具体晚到什么时候，不保证网络已经就绪、磁盘已经挂载完。如果你的 Tomcat 启动太早，网络栈还没准备好，端口绑定失败就起不来了。最坑的是这种失败不会自动重试，你只能等 reboot 之后手动去救。

第二，没有进程守护。进程崩了不会自动拉起，和 SysV 是一样的毛病。

第三，没有标准状态查询接口。systemctl status tomcat 这类操作在 rc.local 方案下完全不可用。

所以如果你只是自己开发用，rc.local 可以接受。生产环境还是老老实实写 service 单元吧。

5. 配了自启之后，服务还是起不来的排查思路

这是文章的重头戏，也是我觉得最有价值的部分。以下每个问题都是我实际踩过、帮别人排查过的，不只是理论推断。

5.1 先确认服务有没有被 enable

这是个看着可笑但出现频率极高的问题。很多人配置完没执行 systemctl enable，只是手动 systemctl start 成功了，然后 reboot 发现服务没了。

检查方法：

bash复制systemctl is-enabled tomcat

如果输出不是 enabled，那开机不会启动。执行：

bash复制systemctl enable tomcat

5.2 手动 start 成功，systemd 里却起不来

现象：你直接跑 /opt/tomcat/bin/startup.sh，Tomcat 能起来，但通过 systemctl start tomcat 就失败，systemctl status tomcat 里能看到类似这样的报错：

code复制The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program

原因就是我前面说的：systemd 环境不加载 /etc/profile。解决方式二选一：

在 service 文件里加 Environment=JAVA_HOME=/usr/local/java/jdk-17
用 EnvironmentFile 从独立文件加载

我推荐第二种，因为环境变量单独管理，后续要改 Tomcat 运行内存、调 GC 参数，不用动 service 文件。

5.3 Tomcat 能启动，但 PID 文件路径不对

Type=forking 配合 PIDFile 有个隐含要求：PID 文件里的进程必须是启动脚本拉起的主进程。Tomcat 的 startup.sh 默认生成 PID 文件在 CATALINA_BASE/tomcat.pid，如果你的 CATALINA_BASE 和 CATALINA_HOME 不一致，就要留意 PID 文件的实际位置。

有个判断技巧：启动失败后，先看 /opt/tomcat/logs/catalina.out 里的日志，确认 Tomcat 到底有没有起来。有时候 Tomcat 其实起来了，只是 systemd 认为服务状态不对，因为 PIDFile 路径下的文件不存在或者内容不是有效 PID。

这时可以手动定位：

bash复制find /opt/tomcat -name "*.pid" -type f

然后把 service 文件里的 PIDFile 改对。改完记得：

bash复制systemctl daemon-reload
systemctl restart tomcat

5.4 Permission denied 问题

这类问题在日志里通常长这样：

code复制/opt/tomcat/bin/catalina.sh: Permission denied

如果你给 Tomcat 单独建了 tomcat 用户，而安装目录是你 root 解压的，那么 tomcat 用户可能没有执行权限，或者没有 logs、temp、work 目录的写权限。

解决：

bash复制chown -R tomcat:tomcat /opt/tomcat
chmod -R u+rwx,g+rwx /opt/tomcat

另外一个常见的权限问题是：/etc/tomcat/tomcat.env 文件的权限太宽，systemd 会警告，极端情况下直接拒绝加载。安全做法：

bash复制chown root:tomcat /etc/tomcat/tomcat.env
chmod 640 /etc/tomcat/tomcat.env

5.5 端口被占

Tomcat 默认端口 8080，如果你机器上还跑着别的 Web 服务，或者 Tomcat 没被杀干净，新实例就会启动失败。日志里的典型报错：

code复制SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-nio-8080"]
java.net.BindException: Address already in use

排查：

bash复制ss -lntp | grep 8080

如果发现是残留的 Java 进程占着端口，处理：

bash复制# 查看所有Java进程
ps aux | grep java

# 杀掉残留进程
kill -9 <PID>

还有一个容易忽略的点：检查 Tomcat 配置里的 <Connector> 端口是不是真的 8080，有时候改过 server.xml 里的端口，但自启后你访问的页面还是 8080，自然访问不到。

5.6 setenv.sh 里的内存配置导致启动失败

这个情况后来见得越来越多，因为很多人会按照"Tomcat 运行内存太大需要调整"这类教程，在 bin/setenv.sh 里写：

bash复制export JAVA_OPTS="-Xms1024m -Xmx2048m -XX:MetaspaceSize=256m"

然后配合 systemd 启动，结果报：

code复制Invalid initial heap size: -Xms1024m
Could not create the Java Virtual Machine.

这不是 systemd 的问题，而是 setenv.sh 本身的编码或换行问题。最常见的是 Windows 下编辑脚本后传到了 Linux，导致文件带 CRLF 换行符，bash 执行时把 \r 当成了参数的一部分，-Xms1024m\r 自然无法解析。

检查并修正：

bash复制# 确认文件是否有CRLF换行符
file /opt/tomcat/bin/setenv.sh

# 如果有，转成Unix格式
sed -i 's/\r$//' /opt/tomcat/bin/setenv.sh

另一个罕见但真实存在的情况：setenv.sh 里有中文注释，文件编码又不是 UTF-8，bash 解析时在高版本系统上会报语法错误。处理方式是删掉非 ASCII 字符，或者统一转成 UTF-8 无 BOM 格式。

5.7 看看 journalctl 里到底报了什么

systemd 的日志是排查问题的一手信息源，不要一上来就瞎猜：

bash复制journalctl -u tomcat -n 100 --no-pager

这里 -u tomcat 只看 tomcat 服务单元的日志，-n 100 看最近 100 行，--no-pager 避免日志太长卡在 less 里。加上 -f 参数可以实时跟踪：

bash复制journalctl -u tomcat -f

配合 Tomcat 自己的日志文件，双管齐下基本能定位绝大多数问题。注意 journald 的日志默认不会永久保存，机器重启太多次后老日志可能被重写，所以关键错误当场就要截图或者复制出来。

5.8 另一个隐蔽问题：依赖不满足

如果服务单元里写了 After=network.target，但你的 Tomcat 部署依赖某些磁盘挂载点，比如 /data 是单独的分区，要确保它在 Tomcat 之前挂载完成：

ini复制[Unit]
After=network.target data.mount
Wants=data.mount

data.mount 是 systemd 根据 /etc/fstab 里挂载点自动生成的单元名，需要把路径里的 / 替换成 -。如果没加这个依赖，Tomcat 可能在 /data 还没挂载时就开始读取部署目录，导致应用加载失败。这种错误很隐蔽，因为 Tomcat 本身能起来，但 webapps 下的应用一个都没加载。

6. 配置完自启之后，我建议你做的几件事

服务能开机自启，不代表后面就万事大吉了。根据我这几年的运维经验，还有几个配套动作值得一起做。

6.1 一定要真实 reboot 验证一次

很多人在 systemctl enable tomcat 之后就以为完了，但 enable 只是创建软链接，真正启动流程里还会涉及到环境、网络、依赖挂载等问题。我吃过一次亏：在测试环境配好自启，没验证就下线了，结果生产环境重启后 Tomcat 没起来，查了半天发现是 SELinux 权限问题。

所以配置完，当场 reboot，等它起来后检查：

bash复制systemctl status tomcat
curl -I http://127.0.0.1:8080

这一步做完，这台机器才算是真的"配好了"。

6.2 日志的定期清理

Tomcat 默认日志方式，catalina.out 会一直增长，时间长了磁盘很容易被打满。借助 logrotate 来做日志轮转：

bash复制# /etc/logrotate.d/tomcat
/opt/tomcat/logs/catalina.out {
    copytruncate
    daily
    rotate 15
    compress
    missingok
    notifempty
}

copytruncate 很关键，因为 catalina.out 是 Java 进程持有的文件句柄，如果不复制直接 rename，进程不会自动打开新文件，日志就断了。copytruncate 是先复制内容再清空原文件，进程的句柄不受影响。

注意这是给 systemd 模式下也没有外部 stdout 接管时的方案。如果你的 unit 文件里直接 StandardOutput=journal 接管了日志输出，那 catalina.out 是不会写的，也就没必要 logrotate 了。两种方式各有优劣，我用的是 logrotate 方案，因为不把太多日志塞进 journald，避免 journal 占空间。

6.3 探活脚本，弥补 systemd 的盲区

systemd 的 Restart=on-failure 是在进程异常退出时触发的。但 Tomcat 有时候进程没死，只是应用线程池占满、请求全部超时，此时 systemd 认为服务"还活着"，不会帮你重启。这种情况只能靠外部的健康检查脚本。

我个人的做法是用 curl 检测一个固定路径的 HTTP 状态码：

bash复制#!/bin/bash
# /usr/local/bin/tomcat-health-check.sh
URL="http://127.0.0.1:8080/health"
STATUS=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 3 "$URL")

if [ "$STATUS" != "200" ]; then
    systemctl restart tomcat
    echo "$(date) Tomcat health check failed, restart" >> /var/log/tomcat-health.log
fi

配合 crontab 每两分钟跑一次：

bash复制*/2 * * * * /usr/local/bin/tomcat-health-check.sh >/dev/null 2>&1

这样进程层面崩溃由 systemd 管，应用层面假死由探活脚本管，双层保障才算稳。

6.4 尽量让 JVM 参数从外部文件管理

很多人喜欢在 catalina.sh 或者 setenv.sh 里硬写 JVM 参数。但如果你走 systemd 方案，我更建议把 JVM 参数挪到 EnvironmentFile 里：

bash复制# /etc/tomcat/tomcat.env
JAVA_HOME=/usr/local/java/jdk-17
CATALINA_HOME=/opt/tomcat
CATALINA_BASE=/opt/tomcat
JAVA_OPTS="-Xms1024m -Xmx2048m -XX:MetaspaceSize=256m -Djava.security.egd=file:/dev/./urandom"
CATALINA_OPTS="-Dspring.profiles.active=prod"

注意 systemd 的 EnvironmentFile 里，值带空格和引号时，写法要小心。JAVA_OPTS="-Xms1024m -Xmx2048m" 这种带引号的写法在 EnvironmentFile 里是支持的，但有些老版本 systemd 可能会解析出错。如果遇到问题，可以改用多行无引号写法：

bash复制JAVA_OPTS=-Xms1024m
JAVA_OPTS=-Xmx2048m
JAVA_OPTS=-XX:MetaspaceSize=256m

实际上 EnvironmentFile 反复设置同一个变量，会以最后一次为准，所以这种多行追加并不生效。正确做法是写成一行不带引号，或者接受带引号的写法，并在 systemd-analyze verify 检查一下。稳妥起见，我在生产环境把 JAVA_OPTS 写成一个不带空格拆分的简写，或者用 Environment= 字段写在 service 文件里。

这里我自己的习惯是：如果参数不多，直接在 service 文件的 Environment= 里写，例如：

ini复制Environment=JAVA_OPTS=-Xms1024m\ -Xmx2048m

注意空格前加反斜杠转义。如果参数很多，用 EnvironmentFile，但只在文件里写 JAVA_OPTS=-Xms1024m -Xmx2048m（不带引号），实测没问题。

6.5 多版本 JDK 共存时的显式指定

服务器上可能同时装了 JDK 8、JDK 11、JDK 17，靠 update-alternatives 切换默认版本。如果你在 EnvironmentFile 里不显式指定 JAVA_HOME，systemd 环境里根本不会读 /etc/profile 的配置，那么 catalina.sh 会去 which java 找，找到哪个版本是哪个版本，结果可能和你预期完全不符。

所以，无论 systemd 方案还是 init 脚本方案，JAVA_HOME 一定要写死。这个是我这几年反复强调的一点：不要依赖系统默认 java，Web 容器这种生产级服务，环境和版本必须是显式的。

7. 我踩过的一次比较典型的坑

最后分享一个具体案例。有次给客户配了一台新服务器，CentOS 7，Tomcat 9。我按标准套路写好了 tomcat.service，systemctl enable tomcat 也过了，重启后 systemctl status tomcat 显示 active (running)。结果客户说网站打不开。

我去看了一眼，Tomcat 确实在跑，8080 端口也监听正常，但访问就是白屏。查了 catalina.out，发现里面没有任何异常日志。后来用 curl http://127.0.0.1:8080 一看，返回了 404。再翻一下 Tomcat 的 webapps 目录，发现客户把项目 war 包放错了位置，放在了 /opt/tomcat/webapps.bak 下面，而不是 /opt/tomcat/webapps 下。

这个案例其实和开机自启本身没有直接关系，但它说明了另一个问题：开机自启配置好，只是解决了"起不起来"的问题，不解决"起来之后部署的东西对不对"的问题。排查时一定要分清楚是服务层的问题还是应用层的问题。

如果你在重启后遇到类似"Tomcat 在跑但页面 404"的情况，排查路径应该是：

确认访问端口对不对：ss -lntp | grep java
确认请求的路径对不对：ls /opt/tomcat/webapps/
确认应用是否真正完成部署：tail -f /opt/tomcat/logs/catalina.out | grep "Deployment"
确认项目里的数据库连接、Redis 地址等外部依赖是否就绪

做完这四步，绝大多数"启动成功但访问失败"的问题都能定位。

我在实际项目中还有一个习惯，就是每次调整完 service 文件后，统一执行一遍：

bash复制systemctl daemon-reload
systemctl restart tomcat
systemctl status tomcat

这个三步曲看起来简单，但确实能挡住一大部分"改了配置但没生效"的尴尬情况。最后再分享一个收尾的小技巧：配置完自启，在改动系统环境或升级 JDK、Tomcat 后，最好重新跑一次 systemctl daemon-reload 和开机验证，不然花了半小时配置的自启，可能因为一次安全补丁升级就悄悄失效了。