为什么 Bash 脚本总是不稳定？

写过很多 Bash 脚本的人都知道，Bash 的坑不是一般的多^。所以大家都认可应该用 Python 而不是 Bash 的一个理由就是 Bash 脚本不可靠，不仅运行不稳定，而且还很难维护。关于 Bash 脚本很难维护，在《关于 Bash 的 10 个常见误解》里面有提到，其实是很多人对于 Bash 的语法就根本不熟悉。连最常用的 if 表达式的语法都不甚了解，更何谈什么进程替代啊，或者来做Bash 脚本的单元测试呢？没有人会认为使用一个自己不熟悉的语言来做开发维护工作是一件容易的事情。

不过呢，就算是我们对 Bash 语法不熟悉，但我们只是来实现一个简单的功能。Bash 脚本也没写几行，甚至在命令行都一条一条的验证过，放到 Bash 脚本里面运行起来就是会莫名其妙的出错。有些在服务器上的出错根本没法儿在本地重现，本地测试的好好的，刚部署上去也好好的，一到晚上或者假期就是各种出错。所以，有人说这是因为 Bash 这个语言其实不严禁，导致其运行不可靠，不稳定，所以得用 Python。但同样的功能用 Python 实现起来的代码量比 Bash 多，所以只是为了个简单的功能，还是直接写到 Bash 脚本里面吧，在 Python 脚本里面用 os.command 把很多命令一个一个包装起来也是挺烦人的。

从一个简单的例子开始

下面我们就以一个简单的例子来看一下为什么 Bash 脚本会如此不可靠。用 Bash 脚本为 GNU/Linux 实现一个很常见的、也很简单的功能，重启 Tomcat 服务。

Tomcat 是 Java 开发里面很常见的一个服务器应用，安装和使用都很简单。只要系统上已经安装了对应的 JDK，配置好 JAVA_HOME 环境变量，把 Tomcat 下载回来后解压就可以使用了。在 Tomcat 的安装目录里面执行 ./bin/startup.sh 就可以启动 Tomcat 服务，运行 ./bin/shutdown.sh 就可以停止 Tomcat 服务。

如果你读到这里，请稍微暂停来思考一下：如果由你来实现「重启 Tomcat」这个脚本，需要考虑哪些情况呢？

重启 Tomcat 服务，无非就是先「停止」再「启动」就可以了。我们在命令行的 Tomcat 目录下执行了 ./bin/startup.sh 后，打开浏览器验证了 Tomcat 已经启动。然后再执行 ./bin/shutdown.sh，再次打开浏览器发现无法访问了。所以要重启 Tomcat 就是先后执行这两个命令就可以了。

但是有一个要考虑的，如果 Tomcat 已经停止了，再次执行命令来停止 Tomcat 会不会出错呢？我们在命令行下测试了反复执行 ./bin/shutdown.sh 之后，发现除了打印出一个无关紧要的可以被忽略的出错信息后，执行过程并不会出错。

看起来实现重启 Tomcat 这个功能的 Bash 脚本无非就是要做如下几步：1、切换到 Tomcat 的安装目录；2、停止 Tomcat；3、启动 Tomcat。

#!/bin/bash
export JAVA_HOME=/opt/jdk1.8.0_262
export PATH="$JAVA_HOME/bin:$PATH"
cd /home/chaifeng/apache-tomcat-8.5.57
./bin/shutdown.sh
./bin/startup.sh

为了防止 Bash 脚本没有获取到 JAVA_HOME 这个环境变量的设置，我们在脚本里面还额外设置了一下，这又能避免一些奇怪的场景下无法获得这个变量的问题。看起来这个脚本很完美了，在本地也执行了一下，确实如我们期望的 Tomcat 已经重启了。用 ps 命令也确认了重启前后的 java 进程 ID 也发生了变化。

但是当我们把这个脚本部署到服务器上以后，情况却不一样了，大部分时候这个脚本都无法重启 Tomcat。明明 Tomcat 已经运行，但是服务端口处于无法访问的状态，甚至还会出现好几个 Tomcat 进程。难道是 ./bin/shutdown.sh 不起作用吗？当我们登录到服务器上，用 kill -9 杀掉这些 java 进程后，手动执行命令启动 Tomcat，验证没有问题。然后再手动运行命令停止 Tomcat，发现也没问题。更诡异的是，不管我们在命令行反复测试多少次，这两个启动和停止命令都正常工作。

明明在命令行下测试过都正常工作的命令，只有放到 Bash 脚本里面执行才有问题。看来 Bash 脚本的执行确实有时候不知何故的会出问题。难道真的是 Bash 是个不严禁的语言，运行不稳定吗？

为什么连这个简单的 Bash 脚本都运行不稳定？

为什么在命令行下一条一条的执行 Bash 脚本中的命令都没有问题，但是放到一个脚本中执行却会出问题呢？这两种方式下的命令都一样，除了用 Bash 语言不严禁这个理由来解释外，好像也没什么其他原因了。

实际上，有一个很重要的因素很容易被我们所忽略，就是：两条命令执行之间的时间差。

在命令行上手工执行 Tomcat 的停止命令 ./bin/shutdown.sh 后，到输入了启动命令 ./bin/startup.sh 准备按下回车键执行之间，已经过去了好几秒。即使我们是快速复用命令行的历史命令，也要耗费2、3秒。而放到一个脚本里面执行，前一个命令执行结束到下一个命令开始运行，中间大概只有几个毫秒的时间差。几秒与几毫秒的时间差的区别就是这个简单的重启 Tomcat 脚本运行不稳定的根本原因。

当执行了 ./bin/shutdown.sh 来停止 Tomcat，实际上只是给 Tomcat 服务器发送了一个「停止」的信号，然后命令就退出。但此时，Tomcat 收到了「停止」信号后开始运行停止前的清理任务，包括但不限于等待尚未结束运行的客户端连接、释放数据库资源、网络资源、清理临时文件等。所以 Tomcat 还在运行，并没有立刻停止。这个停止运行前的清理工作的耗费时间依据我们的项目不同可能会差别很大，从零点几秒到几十秒，甚至几分钟都有可能。所以，这里是第一个关键的地方，./bin/shutdown.sh 命令执行结束后，Tomcat 可能还在后台进行清理工作，而没有停止运行！

等我们输入了 ./bin/startup.sh 后，时间已经过去了几秒，这个时间差已经足够让 Tomcat 在大多数的情况下真正停止运行了。所以 Tomcat 就又正常启动了。

放在脚本中运行，由于两条命令之间的时间差可能只有几毫秒，这么短的时间不足以让 Tomcat 停止运行。当我们在本地测试运行这个 Bash 脚本时，停止命令和启动命令都已经先后结束运行后。此时在后台，前一个老 Tomcat 进程还尚未结束运行，一个新的 Tomcat 进程就已经启动。但这个新的 Tomcat 可能还需要几秒钟来初始化资源，才能够开始绑定服务端口，这又为老 Tomcat 进程的停止争取到宝贵的几秒时间。当这个新的 Tomcat 结束了资源初始化后开始绑定服务端口的时候，老 Tomcat 可能已经释放了这个服务端口并停止运行。所以在本地测试时，这个重启 Tomcat 的 Bash 脚本表现的非常完美。

当部署到服务器上以后，Tomcat 服务可能会因为资源使用很多而需要更久的时间来释放资源，仅仅几秒是不够的。这就使得当一个新的 Tomcat 结束了资源初始化后，由于老的 Tomcat 服务还没有结束资源释放且没有释放服务端口，导致新的 Tomcat 会因为服务端口被占用而启动失败。

这就是为什么这么简单的一个重启 Tomcat 的 Bash 脚本会出现运行不稳定的原因。而且也不会因为我们用 Python 重写这个 Bash 脚本就可以解决这个问题。

让这个简单的例子变的稳定

既然找到了原因，那就好说了，启动 Tomcat 之前先把现有的 Tomcat 进程杀掉。因为 Tomcat 本身是一个 Java 应用，所以也就是杀掉 java 进程。

现在的问题是「如何杀掉进程」。有人会说这很简单啊，用 kill -9 就可以杀掉进程。没错，这样的确可以。而且如果大家去搜索「Linux 杀掉进程」，很多的搜索结果都提到要用 kill -9 来杀掉进程。为什么要使用选项 -9 呢？有人会说，因为有时候直接用 kill 命令杀不掉进程，反复执行也杀不掉，用了选项 -9 之后就可以了。

事实上，kill -9是对系统危害最大的命令之一。也有人会说，我一直用 kill -9 来杀进程，也从来没破坏过系统啊。这是典型的幸存者偏差，就跟开车不系安全带、骑车不带头盔一样，确实有很多人不系安全带不带头盔，也没见过出事儿。但是只要发生一次，那就是严重伤害。

直接用 kill 命令去杀一个进程，默认是给进程发送了 SIGTERM 信号，当进程收到这个终止信号后，可能会开始终止前的清理工作。当清理工作结束后，该进程就会自行终止，如果不需要清理就直接结束了。如果清理时间稍微长一些，就会让我们产生 kill 命令不工作的错觉。但我们可能只要稍微多等待几秒，进程就会结束了。而使用 kill -9 则类似于一枪爆头，没有给进程在自杀前善后工作的机会。如果进程打开了很大的文件，或者正在写入数据库。暴力终止进程的执行是很有可能会导致文件或者数据库的损坏。

作为一名称职的司机，我们一定会系安全带的。作为一名称职的运维工程师，一定不会滥用 kill -9 这个命令的。现在抬头看看你的周围，有多少不称职的运维工程师呢？

既然在执行了停止 Tomcat 的命令后，不能立即强行终止 java 进程，那就需要等待。很显然，我们不能预计要等待多久。如果固定的等待一个比较长的时间，而 Tomcat 早已经停止，这就会让别人觉得这个 Bash 脚本的性能太差了。现在我们修改一下这个重启 Tomcat 的 Bash 脚本：

#!/bin/bash
export JAVA_HOME=/opt/jdk1.8.0_262
export PATH="$JAVA_HOME/bin:$PATH"
cd /home/chaifeng/apache-tomcat-8.5.57
./bin/shutdown.sh
for ((i=0;i<60;i++)); do
    pgrep java || break
    sleep 1
done
pgrep java | xargs --no-run-if-empty kill -9
./bin/startup.sh

新增了一个等待循环，每秒钟都检查一下 java 进程，如果没找到就终止循环，最多等待 60 秒。退出循环后，再次查找 java 进程，这里用了 GNU xargs 的选项 -—no-run-if-empty 可以避免 xargs 没有从管道接受了数据而去执行 kill -9 命令，导致无谓的出错。

到这里，这个简单的重启 Tomcat 的 Bash 脚本看上去没啥问题了，不管是本地还是服务器上都可以正常的稳定的工作了。而且我们应该也要注意到，讨论的这个问题不管我们用 Python 还是 Bash 还是其他什么语言来实现这个功能，都同样是需要考虑的。要承认，这个造成 Bash 脚本运行不稳定的原因与 Bash 一点儿关系都没有。

这个简单的例子还没有结束

看到这里，或许有人会疑惑还需要考虑什么呢？停止 Tomcat 后，如果在 60 秒内 Tomcat 还没有停止就会强制停止，然后再启动 Tomcat。完美，没什么要考虑的了。

如果在系统上除了 Tomcat 这个 java 进程外，还有其他的 Java 进程，我们怎样确保这个重启脚本不会杀掉其他无关的 Java 进程呢？

如果 Tomcat 是以某个特定用户来运行，如何阻止其他用户无意中执行这个脚本呢？

如果系统上运行了多个 Tomcat 实例，如果确保这个重启脚本只会重启特定的 Tomcat 而不是其他的 Tomcat 服务呢？

如何能够让不同的 Tomcat 复用同一个重启脚本，而不用是为每个 Tomcat 的安装实例复制多份脚本呢？

如何让这个脚本自动判断 Tomcat 版本并选择对应的 JDK？以避免使用错误的 JDK 来启动 Tomcat 呢？

如何让这个重启脚本自动判断当前目录是否位于一个 Tomcat 安装目录中，运行后重启的就是这个 Tomcat，这样就避免了每次使用可能需要传入 Tomcat 目录作为参数了。万一输入了错误的目录呢？

如何避免使用特权用户执行这个脚本来重启 Tomcat？否则不仅会引入额外的安全风险，也会让因一些文件所有者发生变化而导致非特权用户以后无法再管理 Tomcat。

如何让每次重新开机后可以自动执行这个脚本来重启 Tomcat？如果要做开机自动启动脚本，是不是还要考虑 System V 还是 Systemd ？

作为开机的自动启动脚本时，如何自动判断 Tomcat 的所属用户，并自动切换到该用户的权限下执行？这样可以避免无谓的启动配置。

如果 Tomcat 上部署的服务依赖其他的服务，比如 MySQL，如何让这个脚本自动判断依赖的服务已经运行？避免 Tomcat 启动后服务运行后失败

如何让重启脚本判断 Tomcat 重启后服务已经成功运行，否则将以某种方式发出通知？这样就避免了重启不成功，但是我们不知道。

如何避免这个脚本互斥运行？以防止这个脚本在不同的终端上分别同时运行而导致的运行冲突。

如何避免远程登录到一个服务器上运行了脚本，并确认 Tomcat 运行正常，结果退出登录后，Tomcat 服务也会终止运行的问题。

等等……等等……

为了写出一个稳定、可靠、易用的 Tomcat 重启脚本，我们有很多要考虑的事情。列出了这么多可能需要考虑的问题，有哪个问题是和 Bash 有关的？很显然没有。如果我们用 Python 去开发这样一个功能，是否也需要考虑这些问题呢？答案是肯定的。

结论，Bash 脚本不稳定的原因其实就是我们自己。用 Python 重写 Bash 脚本后，原先该有的问题还是存在，只是我们不能再怪罪是 Python 这个语言不严谨，Python 运行不稳定了。只能乖乖从我们自身去寻找问题，然后慢慢得以解决。

如果一开始我们就能够清楚的意识到我们对于一些基础技能的欠缺，就可以提前避免很多不该有的问题。比如对 Bash 的语法不熟悉，也存在很多的误解，那我们怎么能写好 Bash？缺乏对于操作系统的一些功能理解，比如滥用 SIGKILL 信号，不明白什么时候该忽略 SIGHUP 信号等等，那我们怎么能管理好系统？其次，我们缺乏一个系统的运维知识体系，认为运维工作就是去使用一个又一个的工具，不理解这些工具在运维知识体系中的位置。那我们如何能够有效的利用这些不同工具的组合来解决问题呢？再者，我们缺乏从全局系统角度去思考问题，解决了一个又冒出另一个。或者就没明白这些不同的问题之间可能存在一个共同的根因，总是就问题解决问题，那我们要浪费多少时间和人力才可以维护好一个系统？最后，做好运维工作，提升运维技能不只是运维工程师才需要掌握的。对于开发工程师也有提升自己工作效率，更有效的与运维团队协作和沟通，无论是对自己、对团队、对项目都有好处。

要想了解运维工作的知识体系以及技术脉络请看DevOps 技术栈。再看看你是否也有关于 Bash 的 10 个常见误解？要想写出可靠稳定的 Bash 脚本，那一定要写Bash 脚本的单元测试。