Linux下Tomcat开机自启动：init.d脚本与systemd方案深度对比与实践

1. 项目概述与核心价值

在Linux服务器运维的日常工作中，确保关键服务在服务器重启后能自动恢复，是一项基础但至关重要的任务。Tomcat作为广泛使用的Java Web应用服务器，其开机自启动的配置是每个运维人员和开发者迟早要面对的问题。你可能遇到过这样的场景：半夜服务器机房断电重启，早上接到紧急电话说应用全部无法访问，登录服务器一看，Tomcat根本没起来。手动启动虽然简单，但依赖人工操作就意味着存在风险点和运维盲区。因此，实现Tomcat服务的开机自动启动，是将运维工作从“救火”转向“防火”的关键一步。

网上关于Linux下Tomcat开机自启动的方案很多，但质量参差不齐。有的教程只给命令不讲原理，照做可能出错；有的方案过于复杂，引入了不必要的依赖；还有的方案缺乏健壮性，在真实生产环境中可能掉链子。今天，我将结合自己多年的运维经验，为你深入剖析两种主流方法：一种是基于systemd的现代标准方案，另一种是更为经典和通用的init.d脚本配合chkconfig的方案。正如标题所建议的，我更倾向于推荐第二种方法，原因会在后续详细拆解。无论你使用的是CentOS/RHEL 7+、Ubuntu 16.04+等主流发行版，还是国产化的麒麟、统信UOS等基于Linux的体系，这篇文章提供的思路和脚本都具有很强的参考价值。我们将不仅关注“怎么做”，更会深究“为什么这么做”，以及在实际操作中会遇到哪些“坑”。

2. 两种开机自启动方案深度对比与选型

在动手之前，我们必须搞清楚有哪些路可以走，以及每条路的优缺点。这决定了我们方案的长期稳定性和可维护性。

2.1 方案一：使用Systemd服务单元（现代方式）

systemd是当前绝大多数Linux发行版默认的初始化系统和服务管理器。它为管理服务提供了强大的功能，如依赖关系、日志集成、资源控制等。

2.1.1 Systemd方案的工作原理其核心是为Tomcat创建一个服务单元文件（通常以.service结尾），并将其放置在/etc/systemd/system/目录下。这个文件定义了服务的启动、停止、重启等行为，以及运行时的环境、用户权限等。然后通过systemctl enable命令，在系统启动流程的适当阶段创建符号链接，从而实现开机自启。

2.1.2 Systemd方案的优缺点分析

• 优点：
  1. 功能强大：可以方便地设置资源限制（CPU、内存）、依赖其他服务、自动重启失败的服务等。
  2. 日志统一：服务输出的日志会被journald捕获，使用journalctl -u tomcat.service即可查看，与系统日志整合度高。
  3. 状态管理清晰：systemctl status命令能提供非常详尽的服务状态信息。
• 缺点：
  1. 兼容性依赖：要求系统必须使用systemd。虽然现在很普遍，但在一些老旧的系统或某些特定裁剪过的环境（如某些Docker基础镜像、嵌入式系统）中可能不存在。
  2. 配置相对复杂：单元文件的语法需要学习，对于只想简单实现自启动的用户来说有一定门槛。
  3. 对传统脚本的适应性：如果Tomcat本身通过一个复杂的shell脚本启动（里面设置了复杂的环境变量、JAVA_OPTS等），需要将这些逻辑正确地迁移或封装到Service文件的ExecStart指令中。

2.2 方案二：使用Init.d脚本与Chkconfig（经典通用方式）

这是Linux系统传统的服务管理方式，通过Shell脚本实现服务的生命周期管理，并利用chkconfig或update-rc.d工具来管理运行级别。

2.2.2 Init.d方案的工作原理我们编写一个符合LSB（Linux Standard Base）规范的Shell脚本，这个脚本必须能响应start、stop、restart、status等标准参数。将该脚本放置在/etc/init.d/目录下，并赋予可执行权限。然后，使用chkconfig --add命令将该脚本添加到服务管理列表，并设置其在指定运行级别（如3, 5）下自动启动。

2.2.2 Init.d方案的优缺点与推荐理由

• 优点：
  1. 极高的兼容性：从古老的SysV init到现代的systemd系统，都兼容这种方式。systemd会兼容并模拟init.d脚本的行为。这意味着同一套脚本，几乎可以在任何Linux发行版上运行，迁移成本极低。
  2. 灵活性极高：脚本完全由你控制，可以用Shell实现任何复杂的启动前准备、环境检查、依赖服务等待等逻辑。它与Tomcat原有的catalina.sh启动脚本能无缝结合。
  3. 直观易懂：脚本内容就是标准的Shell命令，对于运维人员来说可读性和可调试性更强。
  4. 国产化适配友好：许多国产操作系统虽然内核和基础库在演进，但为了保持对历史应用和运维习惯的兼容，对init.d的支持非常完善。采用此方案，在技术路线切换时服务启动层面几乎无需改动。
• 缺点：
  1. 功能不如systemd原生：需要自己实现日志轮转、服务崩溃自动重启等高级功能（当然，也可以通过脚本或结合其他工具实现）。
  2. 管理命令不统一：在纯systemd系统上，你需要使用service tomcat start或/etc/init.d/tomcat start来操作，而不是纯粹的systemctl。

为什么我推荐第二种方法？核心在于“兼容性”和“控制力”。在企业级运维中，服务器的操作系统版本可能五花八门，从CentOS 6到CentOS 8，从Ubuntu 14.04到22.04，还有各种国产OS。一个通用的init.d脚本能让你用同一套方法论应对所有环境，减少环境差异带来的麻烦。其次，Tomcat的启动往往不是简单的一条命令，它涉及到JAVA_HOME、CATALINA_HOME、CATALINA_BASE、内存参数、GC参数、字符集、临时目录等一系列环境变量的设置。将这些逻辑封装在一个独立的Shell脚本里，清晰且便于维护。当需要调整启动参数时，你只需要修改这一个脚本文件。因此，除非你的环境100%确定是较新的systemd系统，且需要用到systemd的独占性高级功能，否则init.d脚本是更稳健、更通用的选择。

3. 核心脚本解析与实操要点

接下来，我们聚焦于第二种方案，深入解读如何打造一个生产级可用的Tomcat自启动脚本。我将提供一个经过大量实践检验的脚本模板，并逐行解释其关键点。

3.1 Init.d脚本模板深度剖析

以下脚本假设你的Tomcat安装在/opt/tomcat目录，运行用户是tomcat。请根据你的实际环境修改。

#!/bin/bash # # chkconfig: 2345 80 20 # description: Apache Tomcat 9.x Web Application Server # processname: tomcat # pidfile: /opt/tomcat/temp/tomcat.pid ### BEGIN INIT INFO # Provides: tomcat # Required-Start: $network $syslog # Required-Stop: $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Apache Tomcat # Description: Apache Tomcat Web Application Server ### END INIT INFO # 1. 环境变量定义 - 这是脚本的核心，必须正确配置 export JAVA_HOME=/usr/lib/jvm/java-11-openjdk # 根据你的JDK路径修改 export CATALINA_HOME=/opt/tomcat # Tomcat安装目录 export CATALINA_BASE=/opt/tomcat # 通常与CATALINA_HOME相同，分布式部署时不同 export CATALINA_PID=$CATALINA_BASE/temp/tomcat.pid # 指定PID文件位置，用于status和stop export CATALINA_OUT=$CATALINA_BASE/logs/catalina.out # 标准输出日志 # 可以在此添加应用特定的JVM参数，例如内存设置 export JAVA_OPTS="-server -Xms1024m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m" # 2. 脚本用到的命令路径 TOMCAT_USER=tomcat START_SCRIPT=$CATALINA_HOME/bin/startup.sh STOP_SCRIPT=$CATALINA_HOME/bin/shutdown.sh PROCESS_NAME="java.*$CATALINA_HOME" # 用于ps查找进程 # 3. 源代码函数：获取Tomcat进程PID get_pid() { # 第一种方式：从指定的PID文件读取 if [ -f "$CATALINA_PID" ]; then PID=$(cat "$CATALINA_PID") # 验证PID是否确实存在且是Tomcat进程 if ps -p $PID > /dev/null 2>&1; then echo $PID return 0 else # PID文件存在但进程已死，清理无效PID文件 rm -f "$CATALINA_PID" fi fi # 第二种方式：如果PID文件无效或不存在，则通过ps命令查找 # 使用pgrep更精确，但需确保进程名匹配。这里用ps组合grep是更通用的方法 PID=$(ps -ef | grep "$PROCESS_NAME" | grep -v grep | awk '{print $2}' | head -n 1) if [ -n "$PID" ]; then echo $PID return 0 fi echo "" return 1 } # 4. LSB标准动作函数 start() { echo -n "Starting Tomcat: " pid=$(get_pid) if [ -n "$pid" ]; then echo "Tomcat is already running (pid=$pid)." return 1 fi # 关键步骤：检查必要目录和权限 if [ ! -d "$CATALINA_HOME" ]; then echo "ERROR: CATALINA_HOME ($CATALINA_HOME) does not exist." return 1 fi if [ ! -x "$START_SCRIPT" ]; then echo "ERROR: Startup script ($START_SCRIPT) is not executable." return 1 fi # 以指定用户身份启动Tomcat。使用su或sudo取决于你的权限配置。 # 方式A：如果当前是root，且tomcat用户有权限 if [ "$(id -u)" = "0" ]; then su - $TOMCAT_USER -c "$START_SCRIPT" > /dev/null 2>&1 & # 方式B：如果脚本本身将以tomcat用户执行（通过sudo），或环境已配置好 else $START_SCRIPT > /dev/null 2>&1 & fi # 等待一段时间，确认进程是否成功启动 sleep 5 pid=$(get_pid) if [ -n "$pid" ]; then echo "OK (pid=$pid)." # 将PID写入文件，方便后续管理 echo $pid > $CATALINA_PID return 0 else echo "FAILED. Please check logs: $CATALINA_OUT" return 1 fi } stop() { echo -n "Stopping Tomcat: " pid=$(get_pid) if [ -z "$pid" ]; then echo "Tomcat is not running." # 即使没进程，也清理可能残留的PID文件 rm -f $CATALINA_PID return 0 fi # 先尝试优雅关闭 if [ "$(id -u)" = "0" ]; then su - $TOMCAT_USER -c "$STOP_SCRIPT" > /dev/null 2>&1 else $STOP_SCRIPT > /dev/null 2>&1 fi # 等待最多30秒，让进程优雅退出 for i in {1..30}; do pid=$(get_pid) if [ -z "$pid" ]; then echo "OK." rm -f $CATALINA_PID return 0 fi sleep 1 done # 如果优雅关闭失败，强制杀死进程 echo -n "Failed to stop gracefully, forcing kill... " kill -9 $pid > /dev/null 2>&1 sleep 2 pid=$(get_pid) if [ -z "$pid" ]; then echo "OK (forced)." rm -f $CATALINA_PID return 0 else echo "FAILED to kill process $pid." return 1 fi } restart() { stop sleep 2 start } status() { pid=$(get_pid) if [ -n "$pid" ]; then echo "Tomcat is running (pid=$pid)." # 可以附加更多信息，如进程运行时间 ps -p $pid -o etime= | awk '{print " Uptime:", $0}' return 0 else echo "Tomcat is stopped." return 3 # LSB规范中，3表示服务未运行 fi } # 5. 主逻辑：根据传入的参数调用对应的函数 case "$1" in start) start ;; stop) stop ;; restart) restart ;; status) status ;; *) # 打印标准用法提示 echo "Usage: $0 {start|stop|restart|status}" exit 1 ;; esac exit $?

3.2 脚本关键点与避坑指南

1. chkconfig和BEGIN INIT INFO注释块：这两部分不是给Shell执行的，而是给chkconfig、update-rc.d或systemd等工具读取的元数据。它们定义了服务在哪些运行级别启动(2345)、启动顺序(80)和关闭顺序(20)，以及依赖关系。务必保留且根据实际情况微调。例如，如果你的Tomcat依赖MySQL，可以在Required-Start中添加$mysql。

2. 环境变量设置：这是脚本的灵魂。JAVA_HOME必须绝对正确。CATALINA_PID的指定至关重要，它是脚本管理进程的生命线。我强烈建议显式设置，而不是依赖Tomcat的默认位置（可能在/tmp下，可能被清理）。

3. 用户权限问题：生产环境绝不应该以root用户直接运行Tomcat，这有严重的安全风险。脚本中通过su - $TOMCAT_USER -c来切换用户执行。你需要确保：

   • 系统上存在tomcat用户（或你指定的其他用户）。
   • 该用户对CATALINA_HOME目录及其下的logs、temp、work、webapps等目录有读写权限。
   • 如果使用非root用户执行脚本，可能需要配置sudo规则，允许该用户无需密码执行service tomcat命令。

4. get_pid函数的健壮性：这个函数是status、stop、start（检查是否已运行）的基础。它采用了“PID文件优先，ps查找兜底”的双重机制，能有效处理PID文件残留或丢失的情况。ps -ef | grep的匹配模式“java.*$CATALINA_HOME”需要根据你的环境调整，确保能唯一匹配到你的Tomcat进程，避免误杀其他Java应用。

5. 停止逻辑的耐心与果断：stop函数先尝试优雅关闭（shutdown.sh），等待30秒。如果失败，再发送SIGKILL (kill -9)强制终止。这种“先礼后兵”的策略能保证应用有足够时间处理完当前请求和保存状态，避免数据损坏。

4. 实操部署与系统集成全流程

有了脚本，我们还需要正确地将其部署到系统中，并完成开机自启动的配置。

4.1 脚本部署与权限设置

假设你将上述脚本内容保存为tomcat。

1. 复制脚本到init.d目录：

   sudo cp tomcat /etc/init.d/

2. 设置脚本权限：脚本必须可执行。

   sudo chmod +x /etc/init.d/tomcat

3. 创建Tomcat专用用户（如果不存在）：

   sudo groupadd tomcat sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat # 禁止登录shell

4. 修正目录所有权：将Tomcat安装目录及其子目录的所有权赋予tomcat用户。

   sudo chown -R tomcat:tomcat /opt/tomcat sudo chmod -R u+rwX,g+rX,o-rwx /opt/tomcat # 设置合理的目录权限

4.2 使用Chkconfig配置开机自启

在RHEL/CentOS/OEL等使用chkconfig的系统上：

1. 添加服务到chkconfig管理列表：

   sudo chkconfig --add tomcat

   这个命令会读取脚本头部的# chkconfig:行，将服务配置到相应的运行级别。

2. 设置服务开机自启：

   sudo chkconfig tomcat on

   on表示在脚本头定义的默认运行级别（2345）下启用。你也可以用chkconfig --level 35 tomcat on只针对运行级别3和5启用。

3. 验证配置：

   sudo chkconfig --list tomcat

   输出应类似：

   tomcat 0:off 1:off 2:on 3:on 4:on 5:on 6:off

   这表明在运行级别2、3、4、5下，Tomcat服务会自动启动。

4.3 在Systemd系统上的兼容性操作

如果你的系统是Ubuntu 16.04+、CentOS 7+等使用systemd的系统，/etc/init.d/脚本仍然有效。systemd提供了兼容层。

1. 使用systemctl管理传统脚本： 你可以直接使用systemctl命令来操作init.d脚本。

   sudo systemctl start tomcat # 启动 sudo systemctl stop tomcat # 停止 sudo systemctl status tomcat # 状态 sudo systemctl restart tomcat # 重启 sudo systemctl enable tomcat # 启用开机自启（关键！） sudo systemctl disable tomcat # 禁用开机自启

   执行systemctl enable tomcat后，systemd会在/etc/systemd/system/下的相关target目录中创建指向/etc/init.d/tomcat的符号链接，实现自启动。

2. 验证systemd的启用状态：

   sudo systemctl is-enabled tomcat

   应返回enabled。

重要提示：在systemd系统上，虽然可以用service tomcat start，但更推荐统一使用systemctl命令，因为它能提供更详细的状态信息和日志集成。systemctl enable是配置开机启动的关键命令。

4.4 测试服务管理功能

配置完成后，务必进行完整测试：

1. 手动启动测试：

   sudo systemctl start tomcat # 或 sudo service tomcat start sudo systemctl status tomcat

   检查状态是否为active (running)，并查看是否有错误日志。

2. 检查进程和端口：

   ps -ef | grep java sudo netstat -tlnp | grep :8080 # 默认端口8080

3. 停止测试：

   sudo systemctl stop tomcat sudo systemctl status tomcat # 应显示 inactive (dead)

4. 重启测试：

   sudo systemctl restart tomcat

5. 最终极测试：服务器重启： 在测试环境中，执行sudo reboot重启服务器。重启后，等待系统完全启动，然后直接检查Tomcat进程和端口是否已经自动拉起。这是验证开机自启是否成功的唯一标准。

5. 常见问题与排查技巧实录

即使按照步骤操作，你也可能会遇到一些问题。这里记录了几个最常见的“坑”及其解决方案。

5.1 服务启动失败：权限不足

• 现象：执行start命令后很快失败，status显示未运行，查看catalina.out日志发现Permission denied或Cannot create directory等错误。
• 排查：
  1. 检查/opt/tomcat及其子目录（尤其是logs,temp,work,webapps）的所有者和权限。确保tomcat用户有读写权限。
  2. 检查CATALINA_PID指定的目录（如/opt/tomcat/temp）是否存在，tomcat用户是否有写权限。
  3. 如果使用su - tomcat -c方式，确保root用户可以切换到tomcat用户（检查/etc/passwd和/etc/shadow）。
• 解决：

  sudo chown -R tomcat:tomcat /opt/tomcat sudo chmod -R u+rwX,g+rX,o-rwx /opt/tomcat sudo mkdir -p /opt/tomcat/temp sudo chown tomcat:tomcat /opt/tomcat/temp

5.2 服务状态查询不准确

• 现象：Tomcat进程明明在，但service tomcat status却显示stopped。
• 排查：问题几乎都出在get_pid函数上。
  1. 检查CATALINA_PID文件路径是否正确，以及Tomcat是否真的将PID写入了该文件。Tomcat的CATALINA_PID环境变量需要被其启动脚本识别。有时需要在setenv.sh（位于bin目录）中设置CATALINA_PID。
  2. 检查ps -ef | grep的匹配模式PROCESS_NAME。如果服务器上有多个Java进程，可能匹配错误。可以登录服务器，手动执行ps -ef | grep “java.*/opt/tomcat”看是否能唯一匹配到目标进程。如果不行，需要调整PROCESS_NAME变量，例如使用更精确的类路径“org.apache.catalina.startup.Bootstrap”。
• 解决：
  • 确保Tomcat启动时使用了正确的CATALINA_PID。可以在start函数中启动后，强制写入PID作为保障。
  • 优化PROCESS_NAME。一个更稳健的获取PID的方法是：

    PID=$(pgrep -f “Dcatalina.home=/opt/tomcat”)

    前提是Tomcat启动命令中包含了-Dcatalina.home参数（通常startup.sh会设置）。

5.3 开机自启未生效

• 现象：服务器重启后，Tomcat没有自动启动。
• 排查：
  1. 首先确认服务是否真的被启用：运行systemctl is-enabled tomcat或chkconfig --list tomcat。
  2. 检查启动顺序：如果Tomcat依赖的服务（如网络、数据库）没准备好，它可能启动失败。查看脚本头部的Required-Start设置。可以尝试在脚本start()函数的开头加入sleep 10，延迟启动以等待网络就绪。
  3. 查看启动日志：systemd系统可以查看服务启动日志：

     sudo journalctl -u tomcat.service -b # -b 表示本次启动以来的日志

     对于init.d脚本，可以检查/var/log/boot.log或系统启动的通用日志。
  4. 手动模拟启动环境测试：在/etc/init.d/tomcat脚本的start()函数最前面添加env > /tmp/tomcat_start_env.log，然后重启。重启后检查这个文件，看环境变量（尤其是JAVA_HOME）是否在启动时被正确设置。有时系统启动时的环境与用户登录后的环境不同。
• 解决：
  • 在脚本中显式、绝对地设置所有关键环境变量，不要依赖系统级的profile。
  • 在start()函数开始时，添加简单的依赖检查，例如：

    # 等待网络接口就绪 while ! ping -c 1 -W 2 8.8.8.8 &> /dev/null; do sleep 1 done

  • 对于复杂依赖，考虑将服务启动顺序调后（增大chkconfig行中的启动顺序号，如从80改为90）。

5.4 优雅停止无效，总是走到强制Kill

• 现象：每次停止服务，都会等待30秒后触发kill -9。
• 排查：Tomcat的shutdown.sh脚本默认通过向8005端口发送SHUTDOWN命令来停止服务。如果失败，常见原因有：
  1. 端口被占用或配置修改：检查$CATALINA_HOME/conf/server.xml中的<Server port=”8005″ …>端口是否被防火墙阻挡，或者是否被修改。
  2. 停止命令执行用户权限问题：stop()函数中切换用户执行的命令可能因为环境变量问题找不到shutdown.sh。使用绝对路径。
  3. 应用有非守护线程：Web应用中有线程未响应中断，导致JVM无法退出。
• 解决：
  • 确保shutdown.sh脚本路径正确且可执行。
  • 在stop()函数中，可以尝试直接使用$CATALINA_HOME/bin/catalina.sh stop，它比shutdown.sh逻辑更健壮一些。
  • 如果问题持续，可以缩短等待时间（比如10秒），但需要评估应用正常关闭所需的最短时间。

我个人在大量生产服务器上部署的经验是，这个基于init.d的脚本方案成功率在99%以上。最关键的就是前期对环境变量、用户权限和PID管理的细致配置。一旦配好，它就像服务器的基石一样可靠，无论系统如何升级换代，只要Linux还是那个Linux，这套服务管理机制就能持续工作。