Ubuntu 18.04 安装 MongoDB：apt+systemctl+ufw 协同部署指南

1. 项目概述：为什么在 Ubuntu 18.04 上安装 MongoDB 仍值得深挖

MongoDB 是我过去十年里部署频率最高的 NoSQL 数据库之一，尤其在快速迭代的 Web 后端、日志分析系统和内容管理平台中，它那种灵活的文档模型和水平扩展能力，常常比传统关系型数据库更贴合实际业务节奏。但很多人一看到“Ubuntu 18.04”就下意识觉得“太老了，不值得搞”，这恰恰是最大的认知偏差——Ubuntu 18.04 虽然已于 2023 年 4 月结束标准支持，但它仍是大量生产环境、嵌入式边缘设备、教育实验平台和遗留系统的真实底座。我去年接手的一个高校物联网数据采集项目，整套边缘网关就跑在 18.04 上，内核锁定、硬件驱动兼容性、Docker 版本约束都决定了不能轻易升级系统，而 MongoDB 4.0.x 系列正是官方为该版本 Ubuntu 提供长期支持的最后一个稳定分支。所以这不是一个“过时教程”，而是一份面向真实运维现场的生存指南。

你可能会问：现在都 2024 年了，为什么还要抠 Ubuntu 18.04？答案很实在：不是所有服务器都能一键重装，也不是所有团队都有资源做全栈迁移。很多中小企业的测试环境、CI/CD 流水线节点、甚至某些金融行业的沙箱系统，至今仍在用 18.04。我在某家本地 SaaS 公司做技术审计时发现，他们三台核心报表生成服务器，OS 就是 18.04.6，原因很简单——上层 Java 应用依赖特定版本的 OpenJDK 11u，而该 JDK 的某个关键安全补丁只适配到 18.04 的 glibc 2.27。这种“牵一发而动全身”的现实，才是工程师每天面对的战场。因此，这篇内容聚焦的不是“如何安装”，而是“如何在受限环境中，让 MongoDB 稳、准、快地落地并持续可用”。核心关键词MongoDB、Ubuntu 18.04、apt、systemctl、ufw，每一个都不是孤立命令，而是构成服务生命周期管理的四根支柱：apt 是软件供应链的入口闸门，systemctl 是服务状态的神经中枢，ufw 是网络边界的守门人，而 MongoDB 本身，则是整个数据层的心脏。接下来的所有操作，都将围绕这四者的协同逻辑展开，而不是机械地敲几行命令。

2. 安装方案深度拆解：为什么必须放弃官网 tar.gz 包，坚持 apt 方式

在 Ubuntu 18.04 上安装 MongoDB，你其实有三条路可走：一是直接下载官网提供的.tar.gz二进制包手动解压配置；二是通过curl+wget拉取 MongoDB 官方仓库密钥和源列表，再用apt安装；三是使用 Ubuntu 自带的apt仓库（即sudo apt install mongodb）。这三种方式看似只是路径不同，实则背后是三种截然不同的运维哲学和风险等级。我来逐个拆解它们的底层逻辑。

第一种，手动解压 tar.gz。这是最“自由”的方式，你能精确控制二进制文件位置、配置文件路径、日志目录，甚至可以同时部署多个版本共存。但代价极其高昂：你得自己写 systemd service 文件，自己处理用户权限（比如mongod进程该以哪个用户身份运行？/var/lib/mongodb目录的 owner 和 group 是什么？），自己配置日志轮转（logrotate），自己确保启动顺序（比如 MongoDB 是否要等网络就绪后再启动？）。我曾在一个客户现场试过这种方式，结果在一次系统重启后，MongoDB 因为/etc/fstab中挂载的 NFS 存储未就绪而卡死，systemd 等待超时后直接标记服务失败，整个应用链路中断近两小时。问题根源在于，手动部署绕过了 Ubuntu 的包管理系统对依赖和服务生命周期的统一编排。

第二种，添加 MongoDB 官方 APT 仓库。这是 MongoDB 官网文档推荐的方式，理论上能拿到最新版（如 4.4 或 5.0），但对 Ubuntu 18.04 来说，这恰恰是个陷阱。MongoDB 4.4+ 要求 glibc >= 2.28，而 Ubuntu 18.04 的 glibc 版本是 2.27。强行安装会导致mongod启动时直接报symbol lookup error: /usr/bin/mongod: undefined symbol: __cxa_thread_atexit_impl。这个错误信息非常隐晦，新手往往花半天时间去 Google，最后才发现是 libc 版本不兼容。我实测过，在干净的 18.04 虚拟机中执行curl -fsSL https://www.mongodb.org/static/pgp/server-4.4.asc | sudo apt-key add -后，apt update会成功，但apt install mongodb-org会因依赖冲突失败，错误提示是mongodb-org-shell : Depends: libssl1.1 (>= 1.1.1) but 1.1.0g-2ubuntu4.3 is to be installed——这说明官方仓库的包已经不再为 18.04 编译适配。

第三种，使用 Ubuntu 自带仓库的mongodb包。这就是我们最终选择的方案。sudo apt install mongodb安装的是 MongoDB 3.6.3，虽然版本较老，但它经过 Ubuntu 官方 QA 团队的严格测试，与系统内核、glibc、systemd、openssl 完全兼容。更重要的是，它预置了完整的 systemd unit 文件（/lib/systemd/system/mongodb.service）、默认配置（/etc/mongodb.conf）、用户组（mongodb用户和mongodb组）、数据目录（/var/lib/mongodb）和日志路径（/var/log/mongodb/mongodb.log）。这意味着，你敲完apt install，再执行sudo systemctl start mongodb，服务就能跑起来，且所有路径、权限、日志轮转规则都已按最佳实践配置好。这不是妥协，而是对生产环境稳定性的敬畏。就像你不会在手术台上要求医生临时组装一把手术刀，而是直接使用经过灭菌认证的整套器械包一样。apt 方式提供的，就是一个开箱即用、符合 Ubuntu 生态规范的“器械包”。

提示：Ubuntu 18.04 自带的mongodb包，其对应的 MongoDB 版本是 3.6.3，而非 4.0.28。网上搜索到的“mongodb 4.0.28 下载”大多指向 Windows 或 macOS 的安装包，Linux 发行版的二进制分发必须与系统 ABI 兼容，不能跨发行版混用。如果你硬要 4.0.28，唯一可行路径是自行编译源码，但这需要安装 scons、python-dev、boost 等数十个构建依赖，编译耗时超过 40 分钟，且极易因 GCC 版本差异导致链接失败。对我而言，稳定性远胜于版本数字。

3. 核心细节解析：apt、systemctl、ufw 三者协同的底层原理与实操要点

理解apt、systemctl和ufw如何协同工作，是让 MongoDB 在 Ubuntu 18.04 上真正“活”起来的关键。它们不是三个独立命令，而是一个有机的服务治理闭环：apt负责“生”，即软件的引入、依赖解析和初始配置；systemctl负责“养”，即服务的启停、状态监控、自动恢复和资源隔离；ufw负责“护”，即定义服务对外暴露的网络边界。下面我将结合 MongoDB 的具体场景，逐层拆解这个闭环的运作机制。

3.1 apt 的本质：不只是下载器，更是系统级配置编排引擎

很多人把apt当作一个高级版的wget，这是巨大的误解。apt的核心能力在于它的“事务性”和“元数据驱动”。当你执行sudo apt install mongodb时，apt做了远超下载文件的事：

1. 依赖图谱解析：apt会读取mongodb包的control文件，发现它依赖libssl1.1、libgcc1、libc6等 17 个底层库。它会检查本地已安装的这些库版本是否满足要求（例如libssl1.1 >= 1.1.0g），如果缺失或版本过低，会自动将这些依赖加入本次安装计划。
2. 文件系统变更预演：apt会计算本次安装将写入哪些文件（/usr/bin/mongod,/etc/mongodb.conf,/lib/systemd/system/mongodb.service等），并检查目标路径是否被其他包占用或存在冲突。如果/etc/mongodb.conf已被手动修改过，apt会提示你保留原配置还是用新包的默认配置。
3. postinst 脚本执行：这是最关键的一步。mongodb包附带了一个postinst脚本（位于/var/lib/dpkg/info/mongodb.postinst），它在安装完成后自动执行。这个脚本做了三件事：第一，创建mongodb系统用户和组（UID/GID 为 114）；第二，确保/var/lib/mongodb目录存在，并将其 owner 设置为mongodb:mongodb，权限设为755；第三，调用systemctl daemon-reload，通知 systemd 重新加载所有 unit 文件，使/lib/systemd/system/mongodb.service生效。没有这一步，systemctl start mongodb就会报Unit mongodb.service not found。

你可以用dpkg -L mongodb查看该包安装的所有文件，用dpkg -s mongodb查看其详细状态和依赖信息。这才是apt的真实面目——一个嵌入操作系统内核的、具备完整状态管理能力的配置引擎。

3.2 systemctl 的真相：不是简单的启停开关，而是服务健康监护仪

systemctl start mongodb这条命令背后，是 systemd 对服务生命周期的精密控制。它与旧式的service mongodb start（基于 sysvinit 的chkconfig）有本质区别。chkconfig只是简单地 fork 一个进程并返回，而systemctl则建立了完整的“服务契约”。

首先，/lib/systemd/system/mongodb.service文件定义了这个契约：

[Unit] Description=An object/document-oriented database Documentation=man:mongod(1) After=network.target [Service] Type=forking User=mongodb Group=mongodb PIDFile=/var/run/mongodb/mongod.pid # 这里省略了 ExecStartPre, ExecStart, ExecReload 等指令

关键点在于Type=forking。MongoDB 的mongod进程在启动时会 fork 出一个子进程，然后父进程退出。systemctl必须识别这种模式，才能正确跟踪真正的主进程 PID。它通过PIDFile=/var/run/mongodb/mongod.pid这个路径去读取mongod写入的 PID，从而实现精准的进程管理。如果你手动修改了mongod的pidfilepath配置，但忘了同步更新 service 文件，systemctl status mongodb就会显示Active: inactive (dead)，即使mongod进程明明在跑。

其次，systemctl提供了强大的状态反馈。执行sudo systemctl status mongodb后，你看到的不只是“active (running)”，还有详细的日志流（journalctl -u mongodb -n 50 --no-pager），以及内存、CPU 占用率（systemctl show mongodb | grep MemoryCurrent）。更重要的是，systemctl内置了自动恢复策略。在mongodb.service的[Service]段中，有一行被注释掉的Restart=on-failure。如果你取消注释并执行sudo systemctl daemon-reload，那么当mongod因 OOM 被 kill 或崩溃退出时，systemd 会在 100ms 后自动重启它，无需任何外部监控脚本。这是我在线上环境强制启用的配置，它让服务的 MTBF（平均无故障时间）提升了 300%。

3.3 ufw 的逻辑：防火墙不是“开个端口”那么简单，而是最小权限原则的落地

sudo ufw allow 27017这条命令，表面看只是放行了 MongoDB 的默认端口，但其背后是严格的网络访问控制哲学。UFW（Uncomplicated Firewall）是iptables的前端封装，它的设计初衷就是让“最小权限原则”变得可操作。

默认情况下，UFW 是inactive状态，这意味着它完全不生效，所有端口都是开放的。执行sudo ufw enable后，UFW 会加载/etc/ufw/before.rules和/etc/ufw/after.rules，设置默认策略：incoming为deny，outgoing为allow。也就是说，从外部进入本机的任何连接，除非你明确allow，否则一律拒绝；而本机主动发起的出站连接（如mongod连接远程配置服务器），则全部允许。这是一个极其安全的基线。

但仅仅allow 27017是远远不够的。你需要思考：谁应该访问这个端口？是本机应用（127.0.0.1），是局域网内的管理机器（192.168.1.0/24），还是某个特定的跳板机（203.0.113.42）？ufw支持精细化的源地址控制：

sudo ufw allow from 127.0.0.1 to any port 27017 # 仅限本机 sudo ufw allow from 192.168.1.0/24 to any port 27017 # 仅限内网 sudo ufw allow from 203.0.113.42 to any port 27017 proto tcp # 仅限特定IP，TCP协议

执行sudo ufw status verbose可以看到每条规则的详细匹配条件。我强烈建议，对于生产环境，永远不要使用allow 27017这种无源地址限制的规则。曾经有个客户因为这条“方便”的命令，导致 MongoDB 被暴露在公网，三天内就被勒索软件加密了所有集合。安全不是功能，而是设计起点。

注意：ufw规则的顺序很重要。UFW 按照规则编号（sudo ufw status numbered）从上到下匹配，第一条匹配的规则即生效。因此，更具体的规则（如from 127.0.0.1）应该放在更宽泛的规则（如from 192.168.1.0/24）之前，否则后者会“遮蔽”前者。

4. 实操过程详解：从零开始的完整安装、配置与验证流程

现在，让我们把前面所有的理论，变成一行行可执行、可验证的命令。整个过程分为五个阶段：环境准备、核心安装、基础配置、安全加固和功能验证。我会在每个步骤后解释“为什么这么做”，并给出实测截图般的文字描述，让你仿佛就坐在我旁边看着终端输出。

4.1 环境准备：清理干扰项，建立纯净起点

在开始安装前，必须确保系统处于一个可预测的状态。Ubuntu 18.04 的默认仓库有时会残留一些旧的、冲突的包。第一步，是彻底更新本地包索引并清理缓存：

sudo apt update && sudo apt upgrade -y sudo apt autoremove -y && sudo apt autoclean

apt update会从/etc/apt/sources.list和/etc/apt/sources.list.d/下的所有文件中，拉取最新的包元数据。apt upgrade -y会升级所有已安装的包到最新版本，-y参数表示自动确认所有提示。autoremove会删除那些因依赖关系而被安装、但现在已无用的包（比如旧版内核），autoclean则会清理/var/cache/apt/archives/中已过期的.deb安装包，释放磁盘空间。这一步看似简单，但至关重要。我见过太多案例，因为apt upgrade没有执行，导致systemd版本过低，无法正确解析新版 service 文件的语法，最终systemctl start mongodb失败。

第二步，检查并禁用可能冲突的服务。Ubuntu 18.04 默认安装了snapd，它有时会与apt安装的软件产生命名空间冲突。执行sudo snap list，如果看到任何非空输出，建议暂时禁用它：

sudo systemctl stop snapd && sudo systemctl disable snapd

另外，确认ufw是关闭状态，避免在安装过程中被意外拦截：

sudo ufw status verbose # 如果显示 'Status: active'，则先禁用：sudo ufw disable

此时，你应该得到一个干净、可控的系统环境。所有后续操作，都基于这个“纯净起点”。

4.2 核心安装：apt install 的完整交互与预期输出

执行核心安装命令：

sudo apt install -y mongodb

-y参数在这里是必需的，因为它会自动回答所有Y/n提示。安装过程大约持续 30-60 秒，期间你会看到类似这样的输出：

Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libboost-filesystem1.65.1 libboost-program-options1.65.1 libboost-system1.65.1 libboost-thread1.65.1 libgoogle-perftools4 libsasl2-2 libsasl2-modules libsasl2-modules-db libsnappy1v5 libssl1.1 libstdc++6 libyaml-0-2 mongodb-clients mongodb-server mongodb-server-data Suggested packages: mongodb-server-hugepages The following NEW packages will be installed: libboost-filesystem1.65.1 libboost-program-options1.65.1 libboost-system1.65.1 libboost-thread1.65.1 libgoogle-perftools4 libsasl2-2 libsasl2-modules libsasl2-modules-db libsnappy1v5 libssl1.1 libstdc++6 libyaml-0-2 mongodb mongodb-clients mongodb-server mongodb-server-data 0 upgraded, 16 newly installed, 0 to remove and 0 not upgraded. Need to get 42.3 MB of archives. After this operation, 142 MB of additional disk space will be used. ... Setting up mongodb-server-data (1:3.6.3-0ubuntu1.1) ... Setting up mongodb-clients (1:3.6.3-0ubuntu1.1) ... Setting up mongodb-server (1:3.6.3-0ubuntu1.1) ... Setting up mongodb (1:3.6.3-0ubuntu1.1) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ...

注意几个关键点：16 newly installed表明apt自动解析并安装了全部 16 个依赖包；Setting up mongodb-server-data是初始化数据目录的步骤；最后一行Processing triggers for man-db表示帮助文档已更新，你可以随时用man mongod查看官方手册。安装完成后，mongod二进制文件位于/usr/bin/mongod，配置文件位于/etc/mongodb.conf，数据目录为/var/lib/mongodb。

4.3 基础配置：修改 mongodb.conf 的三个必改项与一个隐藏坑

Ubuntu 自带的/etc/mongodb.conf是一个精简版配置，它默认开启了bind_ip = 127.0.0.1，这意味着 MongoDB 只监听本机回环地址，外部无法连接。这是安全的默认值，但也是新手最容易卡住的地方。我们需要根据实际需求修改它。

打开配置文件：

sudo nano /etc/mongodb.conf

找到并修改以下三行：

1. bind_ip：这是最关键的。如果你只需要本机应用访问，保持127.0.0.1即可。如果你需要局域网内其他机器访问，改为bind_ip = 127.0.0.1,192.168.1.100（假设本机 IP 是192.168.1.100）。绝对不要设为0.0.0.0，这等于向全世界开放。bind_ip的作用是告诉mongod进程，它应该在哪些网络接口上监听 TCP 连接请求。

2. port：默认是27017，一般无需修改。但如果你的服务器上已有其他服务占用了该端口，可以改为27018或其他未被占用的端口。修改后，记得在ufw规则中也同步更新端口号。

3. logpath：默认是/var/log/mongodb/mongodb.log，这个路径没问题。但你需要确保该目录存在且权限正确：

   sudo mkdir -p /var/log/mongodb sudo chown mongodb:mongodb /var/log/mongodb sudo chmod 755 /var/log/mongodb

一个隐藏的坑是dbpath。/etc/mongodb.conf中默认没有显式指定dbpath，它会使用编译时的默认值/var/lib/mongodb。但如果你之前手动安装过其他版本的 MongoDB，或者误删过该目录，mongod启动时会报错Failed to unlink socket file /tmp/mongodb-27017.sock或Data directory /var/lib/mongodb not found。解决方案是显式声明dbpath：

dbpath = /var/lib/mongodb

并确保该目录存在且权限正确：

sudo mkdir -p /var/lib/mongodb sudo chown mongodb:mongodb /var/lib/mongodb sudo chmod 755 /var/lib/mongodb

这一步做完，保存文件（Ctrl+O,Enter,Ctrl+X），配置就完成了。

4.4 安全加固：ufw 防火墙与 MongoDB 内置认证的双重防护

配置完mongodb.conf，下一步是加固网络层。首先，启用ufw并添加精确的访问规则：

sudo ufw enable sudo ufw default deny incoming # 显式声明，默认拒绝所有入站 sudo ufw allow OpenSSH # 先放行 SSH，避免自己被锁在外面 sudo ufw allow from 127.0.0.1 to any port 27017 # 本机访问 sudo ufw allow from 192.168.1.0/24 to any port 27017 # 内网访问（按需修改） sudo ufw status verbose

ufw status verbose的输出应该类似：

Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere 27017/tcp ALLOW IN 127.0.0.1 27017/tcp ALLOW IN 192.168.1.0/24 22/tcp (v6) ALLOW IN Anywhere (v6)

这表明防火墙已按预期工作。

网络层加固后，是数据库层的认证。Ubuntu 18.04 的mongodb包默认不启用认证，这是为了向后兼容。我们必须手动开启。编辑/etc/mongodb.conf，取消#auth = true这一行的注释：

auth = true

然后重启服务：

sudo systemctl restart mongodb

重启后，MongoDB 会要求所有连接都提供用户名和密码。但此时还没有创建任何用户，所以我们需要先进入无认证模式创建管理员。为此，我们临时注释掉auth = true，重启服务，然后用mongoshell 创建用户，最后再启用认证。

1. 临时禁用认证：

   sudo sed -i 's/^auth = true/#auth = true/' /etc/mongodb.conf sudo systemctl restart mongodb

2. 连接到本地 MongoDB：

   mongo

3. 在mongoshell 中，切换到admin数据库并创建 root 用户：

   use admin db.createUser({ user: "root", pwd: "your_strong_password_here", // 替换为你自己的强密码 roles: [ { role: "root", db: "admin" } ] })

   这条命令创建了一个拥有admin数据库最高权限的用户。roles数组中的root角色，赋予了该用户对所有数据库的全部操作权限。

4. 重新启用认证并重启：

   sudo sed -i 's/^#auth = true/auth = true/' /etc/mongodb.conf sudo systemctl restart mongodb

现在，任何连接都必须带上认证参数：

mongo -u "root" -p "your_strong_password_here" --authenticationDatabase "admin"

4.5 功能验证：从连接测试到基础操作的全流程实操

最后一步，是全面验证 MongoDB 是否真正可用。我们分四个层次进行测试：

第一层：服务状态验证

sudo systemctl status mongodb

预期输出中，Active:应为active (running)，Main PID:后面应跟着一个正整数（如12345），且journalctl -u mongodb -n 20 --no-pager的最后几行应包含waiting for connections on port 27017。这证明服务进程已成功启动并监听端口。

第二层：本地连接验证

mongo -u "root" -p "your_strong_password_here" --authenticationDatabase "admin"

如果成功进入>提示符，说明认证和网络层都正常。输入db.runCommand({ping: 1})，应返回{ "ok" : 1 }，这是 MongoDB 最基本的“心跳”命令。

第三层：基础数据库操作验证在mongoshell 中，执行以下命令：

// 创建一个名为 'testdb' 的数据库（实际创建在第一次插入数据时） use testdb // 创建一个集合 'users' 并插入一条文档 db.users.insertOne({ name: "Alice", age: 30, city: "Shanghai" }) // 查询刚插入的文档 db.users.find().pretty() // 创建一个索引以提升查询性能 db.users.createIndex({ city: 1 }) // 查看当前数据库中的所有集合 show collections

如果所有命令都返回预期结果，说明 MongoDB 的核心 CRUD（创建、读取、更新、删除）功能完全正常。

第四层：远程连接验证（可选）从另一台局域网内的机器（如你的开发笔记本），尝试连接：

# 在你的 Mac 或 Windows 上（需已安装 MongoDB Shell） mongo "mongodb://192.168.1.100:27017/testdb" -u "root" -p "your_strong_password_here" --authenticationDatabase "admin"

如果能成功连接并执行db.runCommand({ping: 1})，则整个安装、配置、加固、验证的闭环就彻底打通了。

5. 常见问题与排查技巧实录：那些文档里不会写的“血泪教训”

在 Ubuntu 18.04 上部署 MongoDB，我踩过的坑比读过的文档还多。下面这些，都是我在真实客户现场、深夜线上故障排查中总结出来的独家经验，它们不会出现在任何官方手册里，但能帮你节省数小时的无效搜索。

5.1 “sudo: apt: command not found” —— 系统 PATH 被破坏的终极信号

这个问题听起来荒谬：apt是 Ubuntu 的基石命令，怎么可能找不到？但它确实会发生，而且往往伴随着更严重的系统异常。根本原因只有一个：你的PATH环境变量被错误地覆盖了。常见诱因是，在~/.bashrc或/etc/environment中，你写了类似export PATH="/my/custom/path"这样的语句，而不是export PATH="/my/custom/path:$PATH"。这导致系统默认的/usr/bin和/bin路径被完全移除。

排查方法：

echo $PATH # 正常输出应包含 /usr/bin:/bin:/usr/local/bin which apt # 应返回 /usr/bin/apt

如果which apt返回空，说明apt不在当前PATH中。

解决方法：

1. 临时修复：export PATH="/usr/bin:/bin:/usr/local/bin:$PATH"
2. 永久修复：编辑~/.bashrc，找到错误的export PATH=行，将其改为export PATH="/my/custom/path:$PATH"，然后source ~/.bashrc。
3. 如果连nano都找不到，可以用vi或cat /proc/1/environ | tr '\0' '\n' | grep PATH查看 init 进程的原始 PATH。

注意：这个问题一旦发生，apt、systemctl、ufw全部失效，因为它们都位于/usr/bin或/bin。所以，它往往是所有后续问题的根源。务必把它作为第一个排查项。

5.2 “command 'nvidia-smi' not found” —— 与 MongoDB 完全无关的“幻影错误”

这个错误信息极具迷惑性。它经常出现在你执行sudo apt update之后，系统提示你安装nvidia-340或nvidia-utils-390。但请立刻停止！nvidia-smi是 NVIDIA 显卡驱动的管理工具，与 MongoDB 的安装毫无关系。这个提示出现，是因为你的系统里安装了nvidia-cuda-toolkit或其他 CUDA 相关包，而这些包的依赖声明中包含了对nvidia-smi的要求。apt在解析依赖时，发现这个命令不存在，于是给出了这个建议。

正确做法：

• 如果你不需要GPU 加速（绝大多数 MongoDB 场景都不需要），直接忽略这个提示。它不会影响 MongoDB 的安装和运行。
• 如果你确实需要CUDA（比如你的 MongoDB 应用集成了 TensorFlow 进行实时分析），那么才需要安装对应的 NVIDIA 驱动。但在 Ubuntu 18.04 上，nvidia-340是非常古老的驱动，仅支持 GTX 600/700 系列显卡，而nvidia-utils-390是 390 系列驱动的配套工具，适用于 GTX 10xx 系列。选择哪个，取决于你的物理显卡型号。

关键结论：nvidia-smi错误是一个“噪音”，不是“信号”。把它当成一个无关的广告，直接关掉即可。不要为了它去折腾显卡驱动，那只会把一个简单的 MongoDB 安装，变成一场灾难性的系统重装。

5.3 “mongodb 启动不了” —— 日志是唯一的真相之源

当sudo systemctl start mongodb执行后，systemctl status mongodb显示failed，这是最让人抓狂的时刻。但请记住：systemctl status只是摘要，真正的线索，永远藏在日志里。

标准排查流程：

1. 看最近 50 行日志：sudo journalctl -u mongodb -n 50 --no-pager
2. 看完整启动日志：sudo journalctl -u mongodb --since "2024-01-01 00:00:00" --no-pager（替换为你的实际日期）
3. 看 MongoDB 自己的日志文件：sudo tail -n 50 /var/log/mongodb/mongodb.log

最常见的错误类型有三类：

• 权限错误：日志中出现Permission denied或errno:13。这几乎总是/var/lib/mongodb目录的 owner 不是mongodb用户。解决方案：sudo chown -R mongodb:mongodb /var/lib/mongodb。
• 端口占用：日志中出现Address already in use。用sudo ss -tulpn | grep ':27017'查看哪个进程占用了端口，然后sudo kill -9 <PID>杀掉它。
• 配置语法错误：日志中出现Failed to parse config file。用sudo mongod --config /etc/mongodb.conf --dryRun进行配置文件语法检查，它会告诉你哪一行、哪个字符出错了。

我有一个铁律：绝不相信systemctl status的摘要，只相信journalctl的原始日志。日志里每一个字，都是mongod进程在崩溃前留下的遗言。

5.4 “sudo systemctl edit 的编辑器如何使用” —— systemd 高级定制的入门钥匙

sudo systemctl edit mongodb是一个强大但被严重低估的命令。它不是用来编辑/lib/systemd/system/mongodb.service这个原始文件（那是危险的，会被apt upgrade覆盖），而是创建一个覆盖（override）文件/etc/systemd/system/mongodb.service.d/override.conf。这个文件里的设置，会叠加在原始 service 文件之上，优先级更高，且不会被系统更新破坏。

典型使用场景：

• 你想让mongod启动时，额外传递一个--wiredTigerCacheSizeGB=2参数来限制内存使用。
• 你想让mongod在启动前，先执行一个自定义脚本（如检查磁盘空间）。

操作步骤：

1. 执行sudo systemctl edit mongodb，这会自动打开一个空白的