解决Python OSError: [Errno 28] 磁盘空间不足错误

2025-01-05 03:15:06

Python 应用磁盘空间不足错误 (OSError: [Errno 28])

在 Python 开发和部署过程中，可能会遇到 “OSError: [Errno 28] No space left on device” 错误。此错误表示设备上没有剩余空间可用于写入数据，导致 Python 应用程序无法正常运行，特别是在尝试进行日志记录或其他磁盘 I/O 操作时。这个错误不仅仅影响 Python 程序，任何需要写入磁盘的进程都有可能遇到。了解问题根源以及采取相应的解决措施至关重要。

问题分析

这个错误的出现，往往并非简单的系统磁盘满载，更有可能指向以下几种情况：

特定挂载点的空间耗尽: 尽管系统全局磁盘空间可能足够，但用于 Python 应用的特定分区或挂载点，如 /app 可能已完全用完。上面的例子就显示/dev/mapper/pyApp--eph-volume--app--484611125--1 也就是挂载在 /app上的分区使用了全部的可用空间，而其他的磁盘空间并没有被用满。
临时文件或日志文件过大: 应用运行过程中产生的临时文件、缓存或日志文件可能没有得到妥善清理，长时间积累导致占用大量空间。持续写入的日志文件是这种情形的典型案例。
其他进程占用资源: 可能是系统或其他应用正在执行大量的写入操作，迅速消耗了磁盘空间。这会造成应用程序无法进行数据写入。
文件句柄泄露: 程序中打开文件却未正常关闭也会导致磁盘空间无法被回收，也会最终造成此类错误。

需要细致的检查才能找出根本原因，这样才能针对性地采取措施。

解决方案

针对不同成因，可以尝试以下多种方法解决问题：

方案一：清理不必要的文件

原因：

特定分区磁盘空间被大量数据文件占据，比如应用缓存或日志。

操作步骤：

确定高占用目录： 使用 du 命令来找出哪个目录消耗了大量的空间，执行sudo du -sh /* --max-depth=1命令可找到根目录下空间使用情况，如果发现例如 /app 使用很高，执行 sudo du -sh /app/* --max-depth=1可继续深挖找出占据磁盘空间的目录和文件。
清理缓存或日志： 删除不再需要的临时文件，例如应用的缓存，或者可以考虑清理旧的日志文件。比如rm /app/your-app-cache/* 可清理指定应用的缓存目录下的内容。注意确认路径。
配置日志滚动: 使用像 logrotate 这样的工具，对日志文件进行滚动和清理，防止其持续增长。例如可以使用 apt install logrotate 来安装日志管理工具，并通过修改其配置文件来配置日志文件的滚动策略，可以参考 /etc/logrotate.d。
针对 Docker 环境: 在 Docker 环境中运行时，需要检查是否 Docker 镜像、容器或其他数据占用过多空间，运行 docker system prune 或清理容器中不需要的数据可以解决。

代码示例

清理临时文件的简单代码：

import os
import shutil

def clean_temp_dir(temp_dir):
    try:
       if os.path.exists(temp_dir):
            shutil.rmtree(temp_dir)
            print(f"cleaned up {temp_dir}")
    except Exception as e:
      print (f"error during removing temp files: {e}")

temp_directory_to_clean = "/app/tmp_dir"
clean_temp_dir(temp_directory_to_clean)

使用 find 命令删除超过指定日期的日志文件：

find /app/log -name "*.log" -mtime +7 -delete # 删除7天前的 .log文件

方案二：增加磁盘空间

原因：

现有磁盘容量不足，难以满足应用正常运行需要。

操作步骤：

查看磁盘情况： 使用 df -h 命令查看当前各个分区的磁盘空间使用情况。
扩展磁盘分区： 如果云服务提供商允许，可以通过控制台扩展磁盘。操作完成后，再用如 resize2fs /dev/mapper/your_lvm_disk 命令扩展文件系统（如果使用了LVM）。

重要安全建议: 在执行磁盘扩展之前，务必备份重要数据。磁盘扩容或分区操作错误可能会导致数据丢失，备份可以让你在意外发生时可以恢复系统。

示例（针对 LVM ）

假设需要扩容逻辑卷： /dev/mapper/pyApp--eph-volume--app--484611125--1，在完成云平台的操作后：

# 列出所有可用的块设备
lsblk

# 找到相关的PV （物理卷）假设名为  /dev/sda2
pvdisplay

# 确认 VG（卷组） 假设名称为 pyApp-eph-volume
vgdisplay

# 找到空闲空间来扩展
vgs

# 假设 找到 可以用来扩展的空间，我们这里来添加一个新的 pv 到VG（pyApp-eph-volume） 假设 pv  为 /dev/sda2 
vgextend pyApp-eph-volume  /dev/sda2

# 使用 lvextend 对 lv（逻辑卷）进行扩容, 例如扩大 5GB
lvextend -L +5G  /dev/mapper/pyApp--eph-volume--app--484611125--1

# 使用 resize2fs 命令 重新设定 文件系统 大小。
resize2fs  /dev/mapper/pyApp--eph-volume--app--484611125--1

# 再次使用 df -h  来检查空间分配情况
df -h

方案三：使用软链接

原因：

一些特定的目录，例如日志或缓存，往往会增长迅速并最终占据大量空间，可以把数据迁移到空间更大的目录。

操作步骤：

找到日志目录: 使用df -h 命令来找出目标目录所在分区。
转移文件： 使用mv命令把文件转移到新的目录下，新的目录需要处于空间比较充裕的分区，可以使用mkdir来创建一个目录。
创建软链接: 使用 ln -s 创建一个从旧路径指向新路径的符号链接，确保应用可以通过旧路径继续访问。

示例

假设原来的日志文件位置 /app/log/ 满了，我们把数据转移到 /log 并且创建链接，假设 /log 的空间很富裕:

#创建新目录，需要确保用户有写入权限
sudo mkdir -p  /log/my-app-log
# 将老数据移到新目录
sudo mv /app/log/*  /log/my-app-log
# 创建软连接，让旧路径重新指向新路径
sudo ln -s  /log/my-app-log /app/log
# 再次使用df -h 查看
df -h

注意: 在使用软链接时务必测试应用功能是否正常，保证链接后不影响应用的运行。

总结

“OSError: [Errno 28] No space left on device” 错误可能出现在各种场景，排查时需要具体情况具体分析，通过清理文件、扩容磁盘或者建立软链接，基本上可以应对大部分情况，但务必在操作前备份数据。采取主动措施，比如监控磁盘空间使用情况，定期清理临时文件，合理配置日志等，是避免此类错误的有效方法。