服务器装 GROMACS、CP2K 装习惯的人，第一次部署 Materials Studio 8.0 多半会愣一下——这软件和常见开源分子模拟工具的安装逻辑不太一样，它有图形化安装器、独立的 License 服务、Gateway 调度层，还要照顾一堆 32 位兼容库。我在某课题组先后部署过两次 MS 8.0，第一次从早上装到天黑，第二次只花了两小时。差别在于第一次直接挂载镜像点下一步，完全没做前置检查；第二次把系统版本、授权文件、远程图形环境这三件事先捋清楚再动手。这篇教程就按照后者的顺序来写，重点覆盖 CentOS 6/7 下 MS 8.0 服务端的完整安装过程、License 授权配置、环境变量和并行计算设置，以及装完以后最常踩的几个坑。适合需要在 Linux 计算节点上部署 MS 8.0 服务端、给 Windows/Mac 客户端提供 Gateway 连接入口的课题组管理员参考。

1. 安装前的三件事：系统版本、授权文件和远程图形环境的确认

1.1 先确认 CentOS 版本和内核架构而不是直接开装

MS 8.0 这个年代的服务端对操作系统版本有明确边界，官方支持范围主要在 Red Hat Enterprise Linux 5/6/7 这一条线上，对应到 CentOS 就是 CentOS 6 和 CentOS 7 最稳，CentOS 8 我没试过，不推荐在项目里拿它硬扛。拿到机器以后第一件事不是找安装包，而是先看清楚三样东西：

cat /etc/redhat-release uname -m df -h /opt

x86_64 架构是基本要求，虽然 MS 8.0 里还有不少 32 位组件，但那是在 64 位内核下用兼容库跑，不是让你真的找一台 i686 机器。磁盘方面，完整安装 MS 8.0 所有模块需要 40GB 左右，如果你的 /opt 是系统盘，最好提前规划单独挂载一块数据盘，避免装到一半提示磁盘空间不足。内存看节点用途，单机做测试 8GB 起步，如果打算跑并行计算子程序，我建议按每个物理核心 2GB 以上预留，后面并行章节会细说。

这里特别提醒一点：MS 8.0 是上世纪风格的老软件，安装目录里会塞大量的链接库、模块文件、帮助文档，如果放在 NFS 网络存储上，安装过程会非常慢，而且个别模块加载容易出怪问题。有条件就把安装根目录放在服务器本地盘，后面没那么多糟心事。

1.2 授权文件决定部署形态：浮动授权还是节点锁定

MS 8.0 用的是 FlexNet 授权机制，拿到手的授权文件通常是一个以 .lic 结尾的文本，里面写着授权类型、允许的 Feature 模块清单、绑定的主机名或 MAC 地址。安装前先搞清楚你拿到的是哪种授权，这直接决定了 License 服务部署在哪台机器上。

如果是节点锁定授权，那授权文件绑定了某一台服务器的 MAC 和 hostname，你就只能在那一台机器上运行 lmgrd，别想着换台机器跑。如果是浮动授权，通常还附带一个独立 License 服务器地址和端口，计算节点只需要在环境变量里写MS_LICENSE_SERVER=port@hostname，指向那台授权服务器即可。

在开始安装之前，有一件特别容易被忽略的事：hostname 的规范化。很多 CentOS 机器装好以后默认叫localhost.localdomain，这种主机名在 FlexNet 授权匹配时非常容易出问题。建议安装前先定一个好记、规范的主机名，比如计算节点叫cnode01：

hostnamectl set-hostname cnode01 echo "192.168.1.10 cnode01" >> /etc/hosts

改完以后要么重启，要么重新登录一次，让 hostname 全局生效。等授权文件到手以后，再对照里面的 HOSTNAME 字段确认大小写完全一致。

1.3 没有显示器怎么装：X11转发与VNC的取舍

MS 8.0 的服务端安装器是 Java 图形界面，在服务器上装就面临一个现实问题：服务器没有显示器。两条路，一是用 SSH X11 转发，二是用 VNC 起远程桌面。

SSH X11 转发听起来简单，ssh -X登录然后跑安装器就行，但实际上跨网络转发 Java Swing 界面非常卡，而且经常出现窗口画不出来、部分按钮点了没反应的情况。我第一次安装就是在这上面耗了不少时间。后来学乖了，直接在服务器上装 tigervnc：

yum install -y tigervnc-server vncserver :1 -geometry 1280x1024 export DISPLAY=:1

VNC 的桌面里开终端，再跑安装器，稳稳当当。如果你对文本操作有经验，还可以用安装器的 console 模式，我自己后面几次就直接./Install -console，文本交互既快又不会因为图形库缺失导致安装器起不来，可以少装一堆图形相关的依赖包。

2. 前置依赖安装：32位兼容库、Java运行时与内核参数调整

2.1 32位兼容库：老版本软件的硬性要求

MS 8.0 服务端的相当一部分核心子程序和授权工具还是 32 位二进制，CentOS 7 默认只有 64 位环境，缺了 i686 兼容库，装到一半或者启动子程序的时候就会报类似error while loading shared libraries: libXp.so.6: cannot open shared object file的错误。

装依赖这一步别省，一次性把常用库装齐，避免装一个缺一个、缺一个装一个的循环：

yum install -y glibc.i686 libXp.i686 libXt.i686 libXtst.i686 \ libXext.i686 libX11.i686 libXau.i686 libXrender.i686 \ libstdc++.i686 compat-libstdc++-33.i686 \ mesa-libGL.i686 zlib.i686 fontconfig.i686

这里面的compat-libstdc++-33.i686是老版本 MS 子程序的常客，它提供的是旧版 C++ 运行时，有的环境不装也能过，但装上以后能避免后面遇到libstdc++.so.5找不到。如果你用的是 CentOS 7，libXp.i686在默认仓库里就能找到；如果 yum 提示找不到，可以用yum provides */libXp.so.6查一下包里位置，再手动装 rpm。

2.2 Java运行时和字体相关包的检查

MS 8.0 安装器自己带了一份 JRE，所以理论上不强制要求你预装 Java。但在实际部署里，部分辅助工具和 Gateway 组件会调用系统 Java，环境里完全没有 Java 还是可能出问题。我的做法是统一装一个 OpenJDK 8：

yum install -y java-1.8.0-openjdk

装完以后可以确认一下java -version正常。要注意，不要在服务器上装一大堆乱七八糟的 JDK 版本然后乱改JAVA_HOME，MS 安装器对 Java 版本不敏感，但对路径里的空格、特殊字符很敏感。以前见过把 Java 解压到带中文的目录里，导致安装器直接白屏，这种环境问题最不值得排查。

另外字体问题也经常被忽略。图形界面花屏、中文变成方块、Gateway 的网页控制台字体异常，很多都和缺少 X11 字体包有关：

yum install -y xorg-x11-fonts-ISO8859-1-75dpi \ xorg-x11-fonts-ISO8859-1-100dpi \ xorg-x11-fonts-type1

2.3 /etc/hosts、防火墙与SELinux的调整

CentOS 7 上默认 firewalld 是开启的，SELinux 也是 enforcing。MS 8.0 的 License 服务和 Gateway 需要监听端口，如果防火墙挡着，客户端就会连接不上，而且这种问题的报错很误导——它可能不是报连接失败，而是在客户端界面里一直转圈。

一般 CPU 计算节点都放内网，我对防火墙的处理很简单：放行 MS 需要的几个端口，然后保持防火墙开启状态，不给课题组留下更大的安全缺口。MS 8.0 通常用到的端口是 License 的27080和 Gateway 的18888：

firewall-cmd --permanent --add-port=27080/tcp firewall-cmd --permanent --add-port=18888/tcp firewall-cmd --reload

SELinux 这块，说实话很多老软件的安装脚本根本没适配 SELinux，与其查各种布尔值，不如对这台计算节点把它设为 permissive。生产环境管理员可能要权衡一下，但对于课题组内部的计算节点来说，这样能省掉大量莫名奇妙的权限阻断问题：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

2.4 离线环境怎么准备依赖包

很多计算节点在内网，没有外网 yum 源，这就非常考验安装前的准备。如果你没有提前把依赖包准备好，到了现场才发现yum install全都失败，那才是真正的地狱开局。

离线环境有两种做法。一种是在有外网的机器上先把需要安装的包连同依赖一起下载下来：

yumdownloader --resolve --destdir=/tmp/ms8_pkgs glibc.i686 libXp.i686 ...

然后把整个目录拷贝到服务器上，用yum localinstall *.rpm装。另一种是直接挂 CentOS 系统安装光盘做本地源：

mount /dev/cdrom /mnt

写一个本地仓库配置文件指向 /mnt，把 gpgcheck 关掉，yum install就能直接从光盘里取包。这个方法对 CentOS 6/7 都有效，缺点是系统光盘仓库里不一定包含所有需要的包，但至少基础兼容库是没问题的。

3. 主安装流程：挂载介质、运行安装器与模块勾选

3.1 挂载ISO镜像与安装目录规划

拿到安装介质以后，上传到服务器某个临时目录。如果是 ISO 文件就挂载：

mkdir -p /mnt/ms80 mount -o loop MaterialsStudio_8.0.iso /mnt/ms80 ls /mnt/ms80

挂载以后看一眼目录结构，找到Install脚本。现在很多 Linux 软件镜像都喜欢用标准的install.sh，但 MS 8.0 这个年代的安装脚本一般就叫Install，后面带上个版本号或者不带。如果执行时提示Permission denied，记得加执行权限：

chmod +x /mnt/ms80/Install

安装目录我建议规划为/opt/msi，MS 安装时会在这个根目录下面按自己的一套逻辑再拆分出多个部分。别自作主张把目录名改成MS80之类的，保持默认风格，后续跟官方文档对照、找文件位置都省事。安装用户也别用 root 直接跑到最后，后面我会说改目录属主的问题。

3.2 安装器交互选项解读

启动安装器有两种方式，图形界面就./Install，文本模式就./Install -console。如果你前面没有开 VNC，我强烈建议直接 console 模式，交互过程不繁琐，逐项输序号、输路径就行，反而比图形界面更不容易卡住。

安装过程中会询问几组关键信息：

• 安装类型：一般选完整安装或者自定义安装。如果介质里包含多个平台组件，注意确认当前选择的是 Linux 版本而不是 Windows 版本。
• 安装根目录：默认通常是/opt/msi，保持默认或改成你规划好的路径。
• 组件列表：这一页会列出所有模块组件，Gateway 是必选的，其他材料计算模块按需勾选。

这里我要强调一个很多人踩过的坑：安装过程中会让你填 License 服务器信息，这个阶段可以先跳过或者随便填一个占位，等主程序装完以后单独再配授权。因为 License 服务的调试经常要反复重启、改 hostname、看日志，如果把它绑在安装流程里一次搞定，出错以后排查链路会很乱。先让主程序落地，再回头收拾授权。

3.3 模块选择策略：别只想省那点空间

模块勾选这里，我的建议是：除非磁盘空间实在紧张，否则全部选上。原因有三个：

第一，MS 模块之间不是完全独立的，很多模块要调用公共数据文件、力场参数库和辅助工具，你少装一个，某个模块可能在运行到一半时才报缺文件。第二，License 是按授权文件里的 Feature 控制每个模块能不能用的，你装全模块不会多消耗授权数，只是占磁盘而已。第三，后续补装模块需要重新跑安装器，而且如果安装器版本或者介质已经被清理，补装成本比现在一次性选上高得多。

如果你确实空间不够，最核心的组件请至少包含：MaterialsVisualizer、Forcite、CASTEP、DMol3、MS Gateway。这几个覆盖了材料计算最常见的结构搭建、分子动力学和第一性原理计算需求。

3.4 安装后的目录结构核对与权限修正

安装过程会持续一段时间，取决于服务器的 CPU 和磁盘速度。装完以后别看安装器提示“Success”就关终端，先把根目录结构过一遍：

ls /opt/msi

正常情况下你应该能看到类似MaterialsStudio8.0、LicensePack、Gateway这样的子目录。如果某个目录缺失，说明对应组件没装上，赶紧回看安装日志，找出是哪个步骤失败。安装日志一般在/tmp下，或者安装根目录下的InstallLogs目录里，报错行会写清楚是在复制哪个文件时失败。

然后做一件很重要的事：把整个安装目录的属主改成非 root 用户。MS 子程序在运行时可能会往安装目录写临时文件、日志，如果用 root 全权持有，客户端任务以普通用户身份执行时反而会遇到权限问题。建议先建一个专门用于运行 MS 的用户：

useradd -m msi chown -R msi:msi /opt/msi

不要小看这一步，后面子程序莫名崩溃，查到最后发现是作业目录无写权限的案例不在少数。

4. License配置：启动License服务与模块授权验证

4.1 License文件放置与方式选择

MS 8.0 的授权服务本质上就是 FlexNet 的lmgrd，授权文件是你从管理员那里拿到的.lic文件。部署方式分两种：

如果课题组有独立的授权服务器，那计算节点根本不用跑 lmgrd，只需要在环境变量里指向它，比如MS_LICENSE_SERVER=27080@license-server。这种方式最省心，License 服务只需要在一台机器上维护，所有计算节点共享。

如果这里是唯一授权节点，或者你想先在一台机器上把服务跑通，就要把.lic放到 LicensePack 的对应目录下。常见的位置是：

/opt/msi/LicensePack/share/licenses/

具体目录名以你介质里的 LicensePack 结构为准，可以用find /opt/msi -name "*.lic"或者find /opt/msi -type d -iname "*licens*"先探路。存放之前，用文本编辑器打开.lic文件，检查里面的 HOSTID 和主机名跟你服务器的实际情况是否一致，不一致的话后面 lmgrd 就算启动成功，客户端也会报 invalid host。

4.2 启动lmgrd并设置开机自启

假定授权服务就在本机，用下面的方式手动启动 lmgrd 做验证：

License_ROOT=/opt/msi/LicensePack/linux_x86_64 $License_ROOT/bin/lmgrd \ -c /opt/msi/LicensePack/share/licenses/MS80.lic \ -l /var/log/lmgrd.log

启动以后第一件事不是急着连客户端，而是看日志。日志里如果出现类似License server started或者FlexNet Licensing version ...字样就说明基本成功了。然后确认端口监听：

netstat -tunlp | grep 27080

我这里用 27080 举例，具体端口要以授权文件里写的信息为准。为了让重启机器后授权服务自动起来，我习惯写一个简单的 systemd 服务。CentOS 7 下在/etc/systemd/system/lmgrd.service里写：

[Unit] Description=FlexNet License Server After=network.target [Service] Type=forking ExecStart=/opt/msi/LicensePack/linux_x86_64/bin/lmgrd -c /opt/msi/LicensePack/share/licenses/MS80.lic -l /var/log/lmgrd.log ExecStop=/opt/msi/LicensePack/linux_x86_64/bin/lmutil lmdown Restart=on-failure [Install] WantedBy=multi-user.target

然后执行systemctl daemon-reload && systemctl enable --now lmgrd。这里注意一个细节：如果你的lmgrd实际是 32 位程序，而系统里没装 32 位库，启动时可能直接报No such file or directory，这不是文件不存在，是加载器找不到对应的 32 位 ld-linux，回到第二章把兼容库补上就好。

4.3 用客户端任务验证授权是否覆盖到模块

License 启动成功不代表所有模块都能用。每个模块对应一个 Feature 名称，比如 CASTEP 对应一个特征码，DMol3 对应另一个。验证授权范围最直接的办法是拿客户端实际提交一个小任务。

在客户端机器上，输入服务端 IP 和登录账号，新建一个简单结构（比如一个小晶胞的几何优化），计算引擎选 CASTEP 或者 DMol3，提交任务。如果授权正常，任务会在服务端排队、运行、最后正常返回结果。如果任务一提交就报错，去 Gateway 日志或者任务日志里找 License 相关的关键词，比如：

• Cannot find license for ...说明授权文件里没有这个模块的 Feature，或者该 Feature 的并发数已经被占满。
• License server system down说明 lmgrd 根本没在跑，或者客户端连不上授权端口。
• Invalid host说明授权文件绑定的主机名跟实际不一致。

验证完一个模块后，最好把几个常用模块都各提交一遍小任务，一次性确认所有模块可用，别到课题组日常计算时才发现某个模块没授权。

5. 环境变量与并行计算：让子程序跑在真正的多核上

5.1 环境变量配置：给所有用户生效

MS 8.0 运行需要的核心环境变量主要是三个：

export MS_INSTALL_ROOT=/opt/msi/MaterialsStudio8.0 export MS_LICENSE_SERVER=27080@cnode01 export PATH=$MS_INSTALL_ROOT/bin:$PATH

MS_INSTALL_ROOT指向 MS 程序主目录。MS_LICENSE_SERVER的格式是端口@主机名，主机名要跟 License 服务器的实际 hostname 一致，如果你写 IP 也可以，但有些模块对 IP 解析方式敏感，尽量写 hostname。PATH里加入 bin 目录后，命令行工具和辅助程序才能被直接调用。

为了让所有登录用户都自动生效，我习惯写到/etc/profile.d/ms8.sh里，然后source /etc/profile或重新登录。这里有个值得提醒的细节：安装目录下的 bin 路径可能不是标准的一层bin，有的模块会把可执行文件放到各自模块目录下的深层路径里，如果你加了 bin 后敲命令还是提示 not found，用ls $MS_INSTALL_ROOT看一下实际结构，把真实的 binaries 路径加到 PATH。

5.2 MPI运行时选择：MS自带的优先

MS 8.0 服务端跑并行计算时，Gateway 会把任务提交给 MPI 运行时执行。有些新装的服务器管理员图省事，系统里装一个openmpi，结果 MS 子程序一跑就崩，或者提交任务后根本起不来并行进程。原因很简单：MS 8.0 适配的是它自带的那套 MPI 运行时和配套的进程管理方式，系统里的 OpenMPI 版本和它不一致时，两边衔不上。

我的做法是：在 PATH 里让 MS 自带的 MPI 目录排在系统 MPI 前面，优先调用 MS 自己的运行时。如果你不确定自带的 MPI 放在哪，找一下安装目录里带mpirun或者mpiexec的路径，比如常见的是$MS_INSTALL_ROOT/../Mpi/mpich/bin，用find /opt/msi -name "mpirun"搜一下。找到后把对应 bin 目录加到环境变量的最前面。

在 Gateway 的任务调度配置里，进程管理器这一项也要选择本机直接执行方式，而不是默认的远程 shell 方式。如果配置成需要 SSH 免密登录，每次任务启动都要多一步 SSH 握手，还容易因为免密没配好导致任务在启动阶段就卡死。

5.3 并行实测：4核、8核、16核的加速比与判断

环境配好了，但怎么确认并行真的生效？我用过一个非常土的办法：跑一个相同的小体系单点能任务，分别设置 1、4、8、16 核，记录每一轮的耗时。

实测下来的数据大致长这样：

从这组数据能看出两件事：一是有加速，说明并行确实在起作用；二是从 8 核到 16 核加速比提升很小，说明这个体系太小，已经出现并行通信开销大于计算收益的情况。如果你提交 8 核任务，但耗时和单核一模一样，那就要怀疑并行没生效。用top看一下运行时进程数量，如果只有一个主进程在跑，说明 MPI 配置有问题，回到 5.2 检查运行时的选择。

体系规模决定核数，这是个特别重要的经验：原子数不到一百的体系，4 核基本就到头了；几百个原子的体系，8 核比较划算；上千个原子的体系才值得上 16 核或更多。无脑加核只会让任务排队排得更久，算得反而更慢。

5.4 磁盘与内存规划：静默失败的常见原因

并行计算对内存和磁盘的要求比想象的更高。MS 子程序在计算过程中会在临时目录产生大量中间文件，/tmp如果空间太小，任务会在没有任何明确报错的情况下消失，只在日志尾部留一行不明不白的错误。这一步我吃过亏：当时一个 32 核任务跑了一个小时后突然退出，查了半天，最后发现/tmp只剩几百兆。

解决办法是把临时目录指到大分区。在 MS 环境里设置：

export TMPDIR=/scratch/ms8_tmp mkdir -p /scratch/ms8_tmp && chown msi:msi /scratch/ms8_tmp

如果/scratch是本地盘，还能顺便减少 NFS 网络文件系统带来的 IO 瓶颈。并行任务如果工作目录挂在 NFS 上，多个进程同时读写同一个网络目录，非常容易出现锁冲突和文件同步问题。有条件的话，把任务的本地工作目录放到计算节点的本地盘，跑完再同步回共享存储，这是老 HPC 管理员的基本素养。

6. 高频问题排查：从错误日志到解决方案的完整链路

6.1 缺动态库：用ldd定位而不是瞎猜

启动 MS 子程序时最常听到的一句话是“报错说找不到一个 .so 文件”。报错信息五花八门，有缺libXp.so.6的，有缺libstdc++.so.5的，有缺libGL.so.1的。面对这类问题，我的排查方式是先找到具体是哪个可执行文件起不来，然后用ldd看它到底缺什么：

ldd /opt/msi/MaterialsStudio8.0/modules/CASTEP/bin/castepexe | grep "not found"

绝大多数情况，缺什么就用包管理器去找它属于哪个包，而不是一次性装一堆包碰运气：

yum provides "*/libXp.so.6"

找到包名后，yum install对应包的 i686 版本。这一套下来通常三五分钟就能解决。不要图省事直接把所有 32 位库装一遍，万一装错版本或者引入了库冲突，后面的排查才是真正的无底洞。

6.2 图形界面显示异常：字体与X环境的处理

MS 安装器或者客户端连接后，界面出现黑块、窗体空白、字体全是小方块，这一般不是程序坏了，而是图形环境和字体的问题。安装器黑屏时先确认DISPLAY有没有指向正确的 VNC 桌面，再确认字体包是否齐全：

xset -q

如果 VNC 分辨率太低，Java 渲染也会出问题，把 VNC 的分辨率调到1280x1024或更高。实在不行就退回文本模式安装，./Install -console不需要 X 也能把主程序完整装上。装主程序和配 License 都不依赖图形界面，图形界面只是给安装过程提供便利，别被它卡住整个项目进度。

6.3 Gateway无法启动：端口与残留进程

Gateway 是客户端连服务器的入口，它的默认端口是 18888。如果你改了 Gateway 配置或者服务器重启后没正常关闭 Gateway，再启动时会提示端口被占用，最常见的场景是安装过程中没有把吉隆的旧进程清干净。

排查链路很直接：

ps -ef | grep -i gateway ss -tlnp | grep 18888

看到 18888 端口被某个 Java 进程占着，要么把它停掉，要么找到 Gateway 自带的启停脚本，用正常方式重启。MS 8.0 网关目录下一般有gwstop、gwstart之类的脚本，先执行 gwstop，确认进程退出以后，再 gwstart。启动后等几秒，再检查一次端口监听是否正常。如果客户端连接时经常自动断开，还要检查客户端到服务器的 18888 端口是否被防火墙拦了。

6.4 License报错：从日志往上游看

License 相关的报错是安装后期的大头。常见的表象有：任务一提交就提示 license 错误、客户端显示无法获得授权、Gateway 日志里写着 license server down。这些表面问题背后可能是完全不同的原因，我的排查套路是从日志出发，一层层往上游看：

先看 lmgrd 的日志：

tail -50 /var/log/lmgrd.log

如果日志显示License server started，说明服务正常，问题可能出在客户端环境变量写的端口或主机名不对。如果日志根本没有启动记录，那 lmgrd 进程可能没起来，检查进程和端口。如果日志里有Invalid host字样，那问题在授权文件绑定信息上，去跟授权文件里的 HOSTNAME 逐一比对。如果日志里有EXPIRED字样，查系统当前时间和日期，FlexNet 对时钟漂移非常敏感，节点时间被自动校时拨乱的时候，授权服务会间歇性地报告过期。

还有一个很容易忽略的坑：修改了/etc/hosts的 hostname 映射后，没有重启 lmgrd。lmgrd 在启动时会把主机名缓存下来，你改了 hosts 但不重启它，它用的还是老名字，自然对不上授权。

6.5 子程序中途消失：内存、磁盘和权限的账

任务提交后进程起来，但跑着跑着就没了，连个报错窗口都不弹，这是最让人头疼的情况。这类问题的排查必须看系统层证据，而不是反复重新提交任务。

先看作业目录下的日志和输出文件，尾部有没有异常。接着看系统日志里有没有内核杀进程的记录：

dmesg -T | tail -50

如果看到Out of memory: Kill process，那就是典型的内存不足，子程序申请的内存超过了节点可用内存，被内核 OOM 杀掉。解决办法是减少并行核数、换大内存节点，或者优化计算的基组复杂度。如果内存没问题，再检查磁盘：

df -h /tmp df -h /opt

临时目录或安装目录满了，程序写中间文件失败，也会静默退出。磁盘没问题的话，接下来检查权限。MS 子程序能不能在工作目录和临时目录写入，取决于 MS 运行用户对这两个目录的权限。用ls -ld看目录属主，用运行 MS 的用户实际去新建一个测试文件试试就知道。这套排查走完，90% 的静默消失都能定位到原因。

说实话，MS 8.0 装好一次以后非常稳定，我见过服务器上跑了好几年都不需要再动的。真正麻烦的从来不是安装本身，而是安装前那些看着不起眼、关键时刻掉链子的前置检查。希望这篇记录能帮你少走几个我走过的弯路。