从根分区满,到业务目录迁移,再到软链接恢复原路径的完整排障记录
本文记录一次银河麒麟桌面系统"输入密码后又返回登录界面"的实际排障过程。案例的关键并不只是解决循环登录,而是通过逐步确认磁盘空间问题,最终将占用根分区的大型业务目录迁移到容量更充足的 /data,并利用软链接保留软件原有访问路径。
**说明:**文中业务软件名称统一使用 XXX_S 代替,用户信息等敏感内容不作展示;/data 下用户目录中的具体清理细节仅保留必要的技术背景,不展开具体删除对象。
一、问题现象
银河麒麟桌面系统开机后能够进入图形登录界面,输入用户名和密码后开始登录,但很快又返回登录界面,无法正常进入桌面。
遇到这类"登录成功后又回到登录界面"的问题,除了检查 LightDM、PAM、桌面环境等组件外,建议首先确认磁盘空间是否耗尽。因为登录过程并不只访问用户家目录,还会涉及系统配置、日志、临时文件以及桌面和后台程序运行所需的数据。
二、切换到 TTY,首先检查文件系统空间
使用 Ctrl + Alt + F2 切换到字符终端,登录后执行:
df -h
现场结果显示,根文件系统 / 已经没有可用空间,而 /data 虽然没有满,但使用率也比较高。这里有一个容易忽略的点:不能看到 /data 还有空间,就直接把 / 下的大目录迁移过去,必须先确认 /data 的实际剩余空间。
三、查看 /etc/fstab,确认 /home 与 /data 的挂载关系
查看系统的静态挂载配置:
cat /etc/fstab

通过系统通过挂载配置可知,该系统将数据分区挂载到 /data;同时 /home 通过绑定挂载等方式指向 /data 下对应目录。因此用户家目录的数据实际存放在 /data分区中。
但是桌面登录过程除了访问 /home 外,还会依赖 PAM、LightDM、系统服务、日志、临时文件以及其他系统组件,其中一部分仍位于根文件系统。若 / 文件系统已经耗尽,相关创建、写入操作可能失败,最终可能表现为输入密码后会话创建失败、桌面启动失败,又返回登录界面。
从文件系统关系上理解,可以简单看成:
/ → 根文件系统
├── /etc
├── /usr
│ └── /local
├── /var
├── /tmp
└── /home → 实际位于 /data 文件系统
/data → 独立文件系统
└── home
└── 用户目录
**这里要注意:**挂载点只是决定数据实际存储在哪个文件系统,登录过程中仍然会使用根文件系统中的多个目录和系统组件。
四、继续排查:分别查看 / 和 /data 下的大目录
确认 / 已满、/data 也存在较高使用率后,下一步不是直接删除文件,而是先定位究竟哪些目录占用了大量空间。
先查看根目录一级目录的空间占用:
du -h / --max-depth=1
结果发现 /usr/local 占用了大量空间。继续查看:
du -h /usr/local --max-depth=1
进一步确认 /usr/local/XXX_S 是主要的大容量目录,占用约 80G。经与用户确认,该目录属于某办公软件的安装目录,并非系统基础目录,因此具备后续迁移条件。
同时,对 /data 进行排查:
du -h /data --max-depth=1
进一步检查 /data/home/用户名后,发现 .local 目录占用空间较大。结合现场实际确认其属于程序运行产生的用户级数据,并在确认无保留需求后进行处理。这里不展开具体清理对象,只保留排障思路:先确认目录用途,再决定是否清理,不能因为目录大就直接删除。
完成必要的空间整理后,/data 剩余空间约 150G。此时再回到业务迁移需求进行判断:XXX_S 约占 80G,/data 当前剩余空间足够,因此具备迁移条件。
五、确定迁移方案:把 /usr/local/XXX_S 移到 /data
既然根分区中的主要空间占用来自 /usr/local/XXX_S,而 /data 仍有足够空间,可以考虑将业务软件目录迁移到 /data,从根分区释放空间。
**迁移前建议:**先停止相关业务进程,并确认业务处于可维护状态;迁移过程优先采用"复制 → 核对 → 切换 → 验证 → 再删除原目录"的方式,避免直接移动或删除导致业务数据不可恢复。
例如可以先使用 cp 保留文件属性进行复制:
cp -rp /usr/local/XXX_S /data/
对于目录较大、需要更细致控制同步过程的场景,也可以考虑 rsync:
rsync -aHAX /usr/local/XXX_S/ /data/XXX_S/
复制完成后,应检查文件数量、目录大小、属主权限等,确认目标目录内容完整,再进行后续切换。
六、迁移后为什么桌面能进,但业务软件打不开?
完成业务目录迁移后,根分区得到释放,系统桌面恢复正常。但进入桌面后发现,原来的业务软件图标点击后无法正常启动。
首先想到的是桌面启动器仍然保存着旧路径。可以查找对应的 .desktop 文件:
find / -name 'XXX*' 2>/dev/null
找到对应的 /usr/share/applications/XXX.desktop 后查看:
cat /usr/share/applications/XXX.desktop
可以看到 Exec、Icon 等字段仍然指向 /usr/local/XXX_S 下的文件。尝试将 Exec 直接改成 /data/XXX_S/CLIENT/XXX.sh 后,软件虽然能够被调用,但服务启动仍然失败。
这说明问题并不只存在于 .desktop 启动器。对于一些较复杂的业务软件,其脚本、配置文件、环境变量或程序内部可能仍然写死了 /usr/local/XXX_S 路径。可以进一步搜索:
grep -r "/usr/local" /data/XXX_S/ \
--include="*.conf" --include="*.ini" --include="*.xml" \
--include="*.sh" --include="*.py" --include="*.cpp" --include="*.h"
如果发现大量程序内部仍然依赖旧路径,逐项修改既耗时又容易出错。此时更合适的思路不是强迫软件适应新路径,而是让原路径继续存在。
七、方案一:使用软链接恢复原始路径
可以在原来的 /usr/local 路径下创建软链接,让 /usr/local/XXX_S 重新指向已经迁移到 /data 的目录:
sudo ln -s /data/XXX_S /usr/local/XXX_S
如果 XXX_S_CONFIG 也被迁移,则同样建立软链接:
sudo ln -s /data/XXX_S_CONFIG /usr/local/XXX_S_CONFIG
检查软链接:
ls -ld /usr/local/XXX_S
readlink -f /usr/local/XXX_S
此时程序访问:
/usr/local/XXX_S
实际访问到的是:
/data/XXX_S
这样既释放了根分区空间,又不需要大范围修改业务软件内部原有路径。完成后重新启动业务软件并验证相关功能,确认软件能够正常启动、业务功能正常后,再视情况清理原目录残留。
**软链接的核心思想:**物理存储位置发生了变化,但对应用程序暴露的访问路径保持不变。对于大量依赖原绝对路径的业务软件,这通常比逐个修改配置文件更加稳妥。
八、方案二:使用 bind mount 保留原路径
除了软链接,还可以使用 Linux 的绑定挂载(bind mount)。它的思路是:把 /data/XXX_S 这个目录的内容,再挂载到 /usr/local/XXX_S,让两个路径看到的是同一份目录内容。
sudo mkdir -p /usr/local/XXX_S
sudo mount --bind /data/XXX_S /usr/local/XXX_S
验证绑定挂载:
findmnt /usr/local/XXX_S
mount | grep '/usr/local/XXX_S'
bind mount 与软链接最大的区别在于实现方式不同。软链接是文件系统中的链接对象;bind mount 则是内核将同一个目录树在另一个挂载点再次呈现出来。它不会因为 bind mount 再复制一份 80G 数据。
九、软链接和 bind mount 如何选择?
|------------|---------------------------|-------------------------|
| 方式 | 特点 | 适用情况 |
| 软链接 | 配置简单、查看直观、维护方便 | 软件能够正常跟随软链接访问目录时优先考虑 |
| bind mount | 原路径仍表现为一个实际挂载点,对部分软件兼容性更好 | 软件对路径、目录属性或链接行为比较敏感时可考虑 |
本案例最终采用软链接,是因为业务软件原有路径依赖较多,使用软链接可以在不大范围修改程序内部路径的情况下恢复原有目录结构。
**实际操作时:**如果软件本身对软链接存在兼容性问题,可以进一步考虑 bind mount;不能认为某一种方式适用于所有业务软件。
十、bind mount 如何实现开机自动挂载?
临时执行 mount --bind 后,重启系统不会自动保留该挂载关系。如果选择 bind mount 并希望系统启动后自动恢复,可以在 /etc/fstab 中增加配置。
/data/XXX_S /usr/local/XXX_S none bind 0 0
/data/XXX_S_CONFIG /usr/local/XXX_S_CONFIG none bind 0 0
修改后可以使用 mount -a 检查配置是否能够正常挂载:
mount -a
确认无报错后,再使用 findmnt 检查实际挂载关系。对于 systemd 系统,修改 fstab 后如有需要可以执行 systemctl daemon-reload 重新加载配置。
**注意:**如果 /data 本身没有正常挂载,依赖 /data 的 bind mount 也无法正常提供业务目录,因此生产环境还应关注 /data 的挂载顺序以及业务服务的启动时机。
十一、案例扩展:能不能把大容量数据盘"给 / 使用"?
这类现场经常会进一步提出一个问题:如果/文件系统容量不足,而机器上有一块很大的数据盘,能不能直接把这部分空间扩给根分区?
如果 / 是普通标准分区,而不是 LVM 等便于在线扩展的结构,就不能简单地理解为"/data 有空闲空间,所以 / 可以直接变大"。两个文件系统即使位于同一块物理磁盘上,也拥有各自独立的空间管理。
如果业务数据本身占用很大,而且不方便改变程序原路径,一个更稳妥的思路是:
原路径:
/usr/local/XXX_S
↓
迁移实际数据
↓
/data/XXX_S
↓
保留原访问路径
↓
/usr/local/XXX_S → /data/XXX_S
这并不是给根分区真正"扩容",而是把特定的大容量目录迁移到另一文件系统,同时通过软链接或 bind mount 保持原有访问路径。对于标准分区环境下的业务数据迁移,这是一个比较实用的思路。
十二、迁移大目录时的注意事项
• 迁移前先确认目标文件系统剩余空间足够,不能只看总容量。
• 先停止业务进程,尽量避免迁移过程中源目录仍在发生写入。
• 优先采用"复制 → 核对 → 切换 → 验证 → 删除"的流程,不要一上来 rm -rf或者mv。
• 注意文件属主、权限、软链接、特殊文件等属性是否完整保留。
• 业务软件可能存在绝对路径依赖,迁移后不能只修改桌面 .desktop 文件就认为问题已经解决。
• 使用软链接或 bind mount 后,要验证业务启动、登录、导入、导出等关键功能。
• 迁移并不等于备份,重要业务数据仍然需要独立备份。
• /data 后续也需要持续关注空间使用率,避免把一个文件系统的问题转移成另一个文件系统空间不足。
十三、案例总结
本次问题表象是"输入密码后无法进入桌面",最终定位到的关键原因是根文件系统空间耗尽。由于 /home 单独位于 /data,即使 /data 仍有空间,也不能直接解决 / 文件系统已经满的问题。
排障过程中,通过 df -h 确认文件系统使用率,再通过 /etc/fstab 理解挂载关系,随后使用 du 分别定位 / 和 /data 下的大目录,最终确认 /usr/local/XXX_S 是根分区的主要空间占用来源。
在确认 /data 经过整理后剩余空间足够的前提下,将业务软件目录迁移到 /data。迁移后,软件又因为内部存在原绝对路径依赖而无法启动,最终通过软链接恢复 /usr/local/XXX_S 原路径,使软件无需大范围修改内部配置即可正常运行。
**这次案例最值得记住的排障思路:**遇到桌面循环登录,不要只盯着 LightDM、PAM 或登录组件等。先确认文件系统空间,再确认挂载关系,再定位具体的大目录;如果根分区空间不足且业务目录占用较大,可以考虑将业务目录迁移到其他文件系统,并使用软链接或 bind mount 保持原路径。
十四、常用命令汇总
|-----------------|------------------------------------------------|
| 目的 | 命令 |
| 查看文件系统空间 | df -h |
| 查看根目录一级目录占用 | du -h / --max-depth=1 |
| 查看 /data 一级目录占用 | du -h /data --max-depth=1 |
| 查看挂载配置 | cat /etc/fstab |
| 查找业务文件 | find / -name 'XXX*' 2>/dev/null |
| 创建软链接 | sudo ln -s /data/XXX_S /usr/local/XXX_S |
| 查看软链接实际指向 | readlink -f /usr/local/XXX_S |
| 创建 bind mount | sudo mount --bind /data/XXX_S /usr/local/XXX_S |
| 查看挂载关系 | findmnt /usr/local/XXX_S |
| 验证 fstab | mount -a |
十五、参考资料
-
GNU Coreutils Manual:ln / symbolic links
-
Linux man-pages:mount(8)、mount(2)、fstab(5)
-
freedesktop.org XDG Base Directory Specification:用户级数据、配置与状态目录规范