x11vnc 启动报 XOpenDisplay failed 的完整排查与解决方案
2026/9/17 0:16:30
如果你正在Linux上给一台机器安装Oracle 19c，第一次运行runInstaller就看见INS-06006，说明你被环境检查拦在了起点。这其实还好办——真正让人头疼的是它后面还跟着INS-44000和INS-32070，三个错误一前一后弹出来，网上查每一个都有不少案例，但很少有人告诉你它们其实是同一个安装流程里三个不同阶段断裂的连锁反应。那几天我在测试机上排障时，刚好把这三个错全踩了一遍，后面还顺带把监听起不来、DBCA建库的坑也趟了，这篇文章就把这些经历完整复盘一遍。
我这台机器当时是CentOS 8.5，跑的是LINUX.X64_193000_db_home.zip，装的是Oracle Database 19c单机数据库软件，准备自己搭一套CDB环境。连续踩完三个坑之后，又碰到了监听服务无法启动和后续建库的问题，所以你会看到这篇文章不只是解释错误码是什么，还会把排查思路、实际执行的命令、以及为什么这样做，一起交代清楚。正在装19c单机或者正准备用DBCA建库的同学，可以直接照着操作。
1. 三条错误码背后的安装链路：为什么它们会连着出现
1.1 一台测试机的安装现场
先还原一下当时的机器环境，方便你对照自己的情况：
- 操作系统：CentOS 8.5，内核4.18.0-348
- 内存16GB，swap 8GB
- 磁盘：根分区40GB，
/u01单独挂载30GB - 安装包：
LINUX.X64_193000_db_home.zip，约3GB - 安装方式：oracle用户解压安装包到
/u01/app/oracle/product/19.0.0/dbhome_1，然后运行./runInstaller
第一次执行runInstaller时，OUI（Oracle Universal Installer）在预检查阶段就弹出了INS-06006，当时界面停留在“Checking operating system requirements”附近。我把提示框截图留了个底，日志里能看到类似这种信息：
INFO: The temp location /tmp is not valid. Please specify a valid temp location. INFO: OUI-10084: The location /tmp is not writable.因为报错很明确是临时目录问题，我第一反应是看/tmp的磁盘占用，果然根分区已经满了。清理完空间后重新运行安装程序，走了没几步又弹INS-44000，这次是OUI在初始化oraInventory时失败。等到把inventory权限修好，第三次运行才终于走到配置Oracle Net Services的阶段，结果又报了INS-32070。
1.2 OUI安装流程的三个关键阶段
这个安装过程可以拆成三个阶段来理解：
| 阶段 | OUI做的事 | 失败时典型报错 |
|---|---|---|
| 预检查阶段 | 检查内核参数、依赖包、磁盘空间、临时目录、权限 | INS-06006 |
| 文件复制与Inventory初始化 | 解压文件到ORACLE_HOME，创建oraInventory并注册安装记录 | INS-44000 |
| 配置阶段 | 执行root脚本、配置Oracle Net、调用网络组件 | INS-32070 |
理解了这三个阶段的职责，你就明白为什么INS-06006、INS-44000、INS-32070会连续出现：前一个错误没解决，后面阶段根本无法正常执行；如果解决了前一个但没注意到后一个的报错条件，又会在下一个阶段继续踩坑。三个错误代码并不是毫无关联的三个独立问题，而是一条链路在三个节点上分别断掉。
1.3 三个错误分别对应哪个环节
我把三个错误码对应到具体环节后，排障思路一下就清晰了：
- INS-06006：预检查阶段临时目录空间或权限校验失败
- INS-44000：全局inventory（oraInventory）目录权限导致安装进程无法写入
- INS-32070：配置阶段执行Oracle Net相关脚本失败，常见原因是系统依赖库缺失
后面所有操作都围绕这三条展开。先处理目录和空间，再处理权限，最后补依赖，这是我认为最合理的顺序。
2. INS-06006：预检查阶段的临时目录陷阱
2.1 报错现象与直接原因
INS-06006的完整报错提示通常是：
INS-06006: Unable to locate a valid temporary directory at the path /tmp.OUI在预检查阶段会向临时目录写入测试文件，然后校验读写能力和可用空间。如果临时目录不存在、不可写，或者空间不足，就会直接中断安装。当时我查了df -h，根分区使用率100%，/tmp完全没空间，别说OUI的临时测试文件，任何用户都没法往里写东西。
2.2 /tmp占用爆满的排查过程
排查占用比想象中麻烦。一开始我用du -sh /tmp看，显示只有800MB，但df -h /明明显示100%。后来才明白，是某个进程占用了已经被删除的大文件，空间没有真正释放。用下面这几条命令找到了元凶：
df -h / du -sh /tmp/* lsof +L1 | grep deletedlsof +L1是查所有被进程打开但已经删除的文件，这类文件在磁盘上不占目录项，但空间不会释放。我当时发现一个解压残留的临时文件仍被shell进程占用，杀掉相关进程后，磁盘空间立刻多出4GB。这个问题在Oracle安装时特别常见，因为安装包解压过程中如果被中断，子进程可能会一直占着删除的文件。
2.3 修复方法：清理、改TMPDIR、换分区
确认根因后，我做了三件事：
- 清理
/tmp下所有可清理的缓存和临时文件，释放出2GB空间 - 杀掉占用已删除文件的后台进程，又释放4GB
- 给安装指定一个更大、更可控的临时目录
如果你也遇到这个报错，又不想反复清理，更稳妥的做法是给OUI单独指定临时目录。在oracle用户的环境变量里加上：
export TEMP=/u01/tmp export TMPDIR=/u01/tmp mkdir -p /u01/tmp chown oracle:oinstall /u01/tmp这样安装时OUI会把临时文件写到/u01/tmp，而不是和系统抢/tmp空间。
2.4 为什么我不建议用-ignorePrereq跳过
网上很多帖子会教你在运行runInstaller时加-ignorePrereq或-ignoreSysPrereqs强制跳过预检查。说实话，我强烈不建议这么干。预检查阶段检测的不只是临时目录，还有内核参数（比如kernel.sem、fs.file-max）、进程数限制、依赖包版本等，这些项如果有问题，跳过检查不一定能装成功，就算装成功了也可能在后续配置阶段甚至运行时爆出更奇怪的错误。INS-06006只是表面现象，根因是环境准备不足，正确做法是把环境修好再装，而不是绕过去。
3. INS-44000：oraInventory权限问题导致的“隐形拒绝”
3.1 报错现象
空间问题解决后，我第二次运行安装程序，走到大概30%的位置，弹出了INS-44000，提示内容整理后大致是：
INS-44000: The Oracle Home Inventory is not accessible. The inventory location /u01/app/oraInventory is not accessible.当时第一反应是：目录存在，为什么不可访问？我用ls -ld /u01/app/oraInventory看了一下，发现目录的属主是root:root，权限是700。也就是说，只有root能进，oracle用户根本写不进去。OUI在初始化inventory时，需要用当前安装用户（oracle）在这个目录下创建日志和记录文件，自然就失败了。
3.2 oraInventory到底是干什么的
oraInventory的全称是Global Inventory，也就是Oracle的全局软件清单目录。它记录的是这台机器上所有Oracle产品的安装位置、组件版本、补丁信息。OUI安装时会往这里写一份inventory，后续DBCA、打补丁、设置ACFS、甚至卸载Oracle都要读它。如果这个目录不可写，安装程序就认为“无法登记软件信息”，于是直接中断。
这个目录的默认位置取决于ORACLE_BASE。如果ORACLE_BASE=/u01/app/oracle，默认会在/u01/app/oraInventory。实际位置由/etc/oraInst.loc文件指定，内容类似：
inventory_loc=/u01/app/oraInventory inst_group=oinstall我当时先看了这个文件，确认指向的位置，然后检查了对应目录权限。
3.3 清理与修复的具体操作
如果你的/u01/app/oraInventory也被root占用了，有两条路可以走：
第一条是直接改属主，这是最省事的：
chown -R oracle:oinstall /u01/app/oraInventory chmod -R 775 /u01/app/oraInventory第二条是如果目录里已经有残缺的安装记录，我建议先把整个目录备份或重命名，再重新安装时让OUI自动创建：
mv /u01/app/oraInventory /u01/app/oraInventory.bak备份比删除好，因为里面可能还记录了之前安装的组件信息，直接删除会影响后续打补丁时识别旧组件。我当时是做了改动后，还顺手确认了/u01/app/oracle整个目录树的属主：
chown -R oracle:oinstall /u01/app/oracle这一步很关键。因为在Linux上，Oracle安装用户必须对ORACLE_BASE路径有完整权限，任何上级目录权限不对，都会引发奇怪的安装中断。
3.4 为什么安装一定要用oracle用户执行
很多新手犯的错是用root直接跑runInstaller，这是官方文档明确不建议的，但很多人还是这么做。root跑安装时，OUI会以root身份初始化inventory目录和相关配置文件，结果就是后续所有Oracle进程都无法访问这些root拥有的文件和目录。更麻烦的是，当oracle用户尝试运行netca、dbca时，也会因为权限问题接连报错。
正确的操作习惯是：安装用户始终用oracle，root只负责在最后阶段执行root.sh和orainstRoot.sh。安装前把/u01/app整个结构都chown给oracle:oinstall，就不会有这种权限纠纷。
4. INS-32070：组件校验被脚本执行失败坑了
4.1 报错现象
第三次安装时，进度条已经走到接近尾声，结果在配置Oracle Net Services的环节又弹出INS-32070。当时日志里大概是这样：
INS-32070: An error occurred during configuration of Oracle Net Services. OUI-XXXXX: Execution of the configuration script failed.这里要说明一下，INS-32070在不同的安装场景下表现可能不完全一样，有的是在执行NetCA时失败，有的是在启动监听服务时失败。我遇到的情况是在“Oracle Net Configuration Assistant”执行过程中中断。它看起来不像前两个错误那么直接，因为你点开日志往往会看到一堆脚本输出，最后才藏着一行真正报错的原因。
4.2 OUI配置阶段到底在干什么
OUI配置阶段会调用一堆脚本来完成网络配置和监听初始化。这些脚本有的是shell，有的是perl或python，运行时依赖很多系统库。如果系统缺少某个动态链接库，脚本直接失败，OUI就会捕获到退出码并把整个配置阶段判定为失败。常见的一个典型场景是RHEL/CentOS 8上默认没装libnsl，而Oracle 19c的网络配置脚本需要用到libnsl.so.1，于是脚本在启动阶段就挂了。
你可以用ldd直接验证某个可执行文件依赖的库是否齐全，但更快的做法是把下面这组依赖包装上：
yum -y install binutils compat-libcap1 compat-libstdc++-33 \ gcc gcc-c++ glibc glibc-devel ksh libaio libaio-devel \ libgcc libstdc++ libstdc++-devel libnsl libxcb \ make numactl numactl-devel smartmontools sysstat \ unixODBC unixODBC-devel注意，不同Linux发行版的软件包名称可能略有差异，比如CentOS 8上compat-libstdc++-33在官方源里不一定有，如果安装时报“No package available”，说明这个包不属于当前源，不需要强行安装，其他基础依赖包保证齐全即可。有些人在配置阶段报错就是因为少装了这些看起来不起眼的库，所以这里值得花时间一次性装完。
4.3 安装包完整性和残留也是隐形元凶
除了系统依赖库，安装包本身不完整也可能导致INS-32070。Oracle 19c的安装包在Linux x86-64平台是一个接近3GB的zip文件。如果你是从非官方渠道下载的，或者下载过程中断过、解压时磁盘空间不足，文件校验不通过，OUI复制到ORACLE_HOME里的组件就会缺胳膊少腿，后续任何配置脚本都可能莫名其妙地失败。
我排障时重新用官方校验值核对了一遍安装包，也检查了解压目录。如果你也遇到类似问题，可以这样操作：
sha256sum LINUX.X64_193000_db_home.zip # 与Oracle官方文档中给出的校验值对比 unzip -q LINUX.X64_193000_db_home.zip -d /u01/app/oracle/product/19.0.0/dbhome_1另外，如果是已经安装到一半失败过，再重新安装之前，一定要清理干净残留。重点检查这几个地方：
$ORACLE_HOME下的残留文件/etc/oratab（如果存在旧记录）/etc/oraInst.loc和/u01/app/oraInventory/etc/rc.d/rc.local里可能被写入的自启动脚本
不清理残留就重新安装，新老配置混在一起，往往会出现比第一次更奇怪的错误。我当时把$ORACLE_HOME目录整个删掉重解压，确定没有任何旧的配置文件残留后，第四次安装才顺利通过。
4.4 依赖包检查的正确姿势
在跑runInstaller之前，Oracle官方文档里有一份完整的RPM依赖清单，但实际排障时与其一个个核对，不如先直接执行上面那条yum install命令装齐基础依赖，再用rpm -q逐个确认：
rpm -q binutils compat-libcap1 gcc gcc-c++ glibc glibc-devel \ ksh libaio libaio-devel libgcc libstdc++ libstdc++-devel \ libnsl libxcb make numactl numactl-devel smartmontools \ sysstat unixODBC unixODBC-devel缺失的包会直接列出来，照着装就行。这比起反复重试安装省时间得多。
5. 三连错快速排障：一条龙检查命令与日志定位法
5.1 推荐排查顺序及理由
三个错误都踩完之后，我总结出一个固定排查顺序，建议你也按这个顺序来：
- 先看磁盘空间和临时目录（因为INS-06006）
- 再看oraInventory和ORACLE_BASE权限（因为INS-44000）
- 再看系统依赖包和安装包完整性（因为INS-32070）
- 最后结合日志确认每个失败的真正原因
为什么要按这个顺序？因为目录空间不足可能导致权限检查时出现误导性报错；权限不足又可能导致配置阶段执行脚本时找不到临时文件。也就是说，前面的问题不解决，后面的排障方向很容易被带偏。
5.2 一条龙命令脚本
我整理了一套可以直接复制执行的命令，你在遇到这三个错误时依次跑一遍：
# 1. 空间检查 df -h / /tmp /u01 mount | grep -E ' /tmp| /u01' du -sh /tmp 2>/dev/null # 2. 权限检查 ls -ld /u01 /u01/app /u01/app/oracle /u01/app/oraInventory 2>/dev/null cat /etc/oraInst.loc 2>/dev/null # 3. 依赖包验证 rpm -q binutils compat-libcap1 compat-libstdc++-33 gcc gcc-c++ \ glibc glibc-devel ksh libaio libaio-devel libgcc libstdc++ \ libstdc++-devel libnsl libxcb make numactl numactl-devel \ smartmontools sysstat unixODBC unixODBC-devel # 4. 日志文件位置 ls -ltr /u01/app/oraInventory/logs/installActions*.log 2>/dev/null tail -200 /u01/app/oraInventory/logs/installActions*.log 2>/dev/null这套命令我每次装Oracle前都会先跑一遍，把它当成“装机前体检”。你不需要等到报错才用，提前跑能避免很多无谓的等待。
5.3 从installActions日志中找主错误
OUI的日志文件位置有几种，取决于安装阶段：
/u01/app/oraInventory/logs/installActions*.log：安装动作的主日志$ORACLE_HOME/cfgtoollogs/oui/installActions*.log：OUI配置阶段的日志$ORACLE_BASE/cfgtoollogs/netca/netca.log：网络配置助手日志$ORACLE_HOME/cfgtoollogs/netca/netca.log：有时候也在ORACLE_HOME下
看日志时不要只盯着INS-开头的那行，真正的错误往往在下面几行。可以用这个方式快速抓重点：
grep -i -E "severe|error|failed|exception" \ /u01/app/oraInventory/logs/installActions*.log | tail -50注意看日志里有没有类似“Cannot write to inventory”“libnsl.so.1: cannot open shared object file”这类描述，这些才是需要解决的根因。INS-06006、INS-44000、INS-32070只是OUI给外部展示的“症状代码”，日志内部才是真正的病因。
5.4 一个常见场景的清单表
我把这次安装中遇到的三个问题整理成一张表，方便你对照：
| 错误码 | 现象 | 根因 | 解决动作 |
|---|---|---|---|
| INS-06006 | 预检查阶段临时目录无效 | /tmp空间不足或磁盘满了 | 清理/tmp、杀释放已删除文件、改TMPDIR |
| INS-44000 | 安装进度30%左右中断 | oraInventory目录权限不对 | chown/chmod修复目录属主 |
| INS-32070 | 配置Oracle Net时脚本失败 | 缺少libnsl等依赖库或安装包不完整 | 安装依赖包、校验安装包、清理残留 |
6. 装完还有后半场：监听起不来与DBCA建库的常见坑
6.1 监听服务无法启动的排查路径
装好数据库软件后，紧接着要跑netca配置监听。很多人到这步会碰到监听服务无法启动的问题。我当时也遇到了，监听配置完成后用lsnrctl status一看，服务是停止状态，手动lsnrctl start又报TNS-01153。排查路径记录一下：
先看主机名解析：
cat /etc/hosts hostname ping $(hostname)如果发现/etc/hosts里没有把这台机器的主机名对应到本机IP，监听进程起不来。Oracle监听默认会把主机名解析到某个IP去监听，解析失败就启动失败。我当时的解决办法是在/etc/hosts里加了一行：
192.168.1.10 db19c另外还有一个高频原因：$ORACLE_HOME/bin/oracle权限不对。Oracle二进制文件需要被设置setuid位，否则监听进程在启动时会因权限不足退出：
chmod 6751 $ORACLE_HOME/bin/oracle ls -l $ORACLE_HOME/bin/oracle正常应该是-rwsr-s--x。如果状态不对，执行上面那行即可。再顺便检查一下防火墙，如果你开了firewalld，需要放行1521端口，或者直接确认监听日志里有没有地址被拒绝的记录。
6.2 单机CDB模式下DBCA的注意点
监听正常后，就轮到用dbca创建数据库。单机CDB（Container Database）环境下，几个细节很容易踩坑：
第一，如果之前安装过其他数据库，/etc/oratab里可能残留旧条目，DBCA读取时会受影响，建议先清理掉。第二，创建数据库之前，把环境变量设置好：
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH export ORACLE_SID=ORCLCDB第三，通过DBCA创建时，默认会创建CDB和至少一个PDB。如果你不想要PDB，在高级模式里取消“Create as Container Database”勾选；如果要保留，建完之后可以这样查看和打开PDB：
sqlplus / as sysdba show pdbs; alter pluggable database ORCLPDB1 open;6.3 软件装好后第一时间做的事
数据库能正常启动后，我建议第一时间做这几件事，否则后面很容易在“等保要求”或日常巡检时手忙脚乱：
- 修改
sys、system默认密码，不要保留安装时的临时密码 - 检查
audit_trail是否开启，满足审计要求 - 用
sqlplus测一次/ as sysdba连接，确认操作系统用户认证正常 - 把监听和数据库实例设置为开机自启动
其中审计这一项在等保相关检查里经常被问到，虽然具体命令每个环境略有差异，但show parameter audit_trail这条可以先跑起来，确认当前状态。
安装Oracle 19c的过程本质上就是不断处理环境和权限问题的过程。从INS-06006到INS-44000再到INS-32070，每一个错误都在提醒你：Linux基础没准备好，后面一定会有连锁反应。我现在装新环境前已经养成了习惯，先把磁盘、权限、依赖包这三项检查做完再动手，安装过程基本不会再被这类错误打断。希望这篇复盘能帮你少走几次弯路。