# 

线上日志偶尔会在某一条记录中间断开，后面的内容整段消失。文件大小正常，进程没退出，磁盘还剩一半空间，重启之后照样在同一类位置开始缺。

第一反应是磁盘写满，查了一圈不是。真正的原因是一处从不检查返回值的写调用：它把「调用了」当成了「写完了」。

## 缺的为什么总是最后几行？

应用层的日志库通常先攒缓冲，攒满一块再整体写出。只要某次写出少写了几个字节，缓冲区里剩下的部分就留在内存里，等下一次继续往后拼——但拼接的起点已经错了。

结果就是文件末尾留下半条记录，或者某一行的开头被下一行覆盖。表现出来像「最后几行不对」，其实是中间某一次写出没写完。

这种错位还有个特点：越接近进程生命周期末尾越明显。进程退出时如果直接结束、没有把缓冲刷出去，内存里剩下的那部分就彻底丢了。

另一种表现更隐蔽：文件看起来完整，但某两行之间少了一个换行，下游按行解析时把两条记录拼成一条。日志量大的服务，这种错误往往是被报表对不上才发现的。

所以「缺最后几行」有两层原因叠在一起：写出时少写，退出时没刷。

## 手册对写操作是怎么说的？

写系统调用的参数含义是「最多写这么多」，不是「必须写这么多」。手册里这句话是整件事的根：

> Note that a successful write() may transfer fewer than count bytes.

翻译过来：一次成功的写调用，实际传输的字节数可能少于请求的字节数。注意前提是「成功」——返回值既可能是你要的全部，也可能只是其中一部分。

所以判断一次写是否完成的依据，不是「没有报错」，而是「返回值等于请求长度」。这条判断如果漏了，后面所有的续写逻辑都不会被触发。

## 哪些情况会导致只写进去一部分？

短写不是异常路径，它属于接口的正常行为。常见的几类：

| 触发条件 | 典型错误码 | 现象 |
| --- | --- | --- |
| 磁盘或配额写满 | ENOSPC | 写到一半返回，剩余需另找空间 |
| 超过单文件大小限制 | EFBIG | 达到上限后无法继续写 |
| 被信号中断 | EINTR | 已写部分生效，需重试剩余 |
| 管道或套接字缓冲满 | 无错误码 | 非阻塞时只写进一部分 |
| 写入长度超过内核单次上限 | 无错误码 | 按上限截断返回 |

第三行容易被误解。如果信号在任何字节写入之前到达，调用直接失败并返回中断；如果已经写进去一部分，调用会成功返回，返回值是已写的字节数。这两种情况的处理方式完全不同。

第四行在日志场景里也不少见：日志先写管道再被收集器读走，收集器一慢，管道就满。

## 按返回值续写该怎么写？

原则只有一句：把「要写的总量」和「已写的量」分开记，循环到两者相等。

```c
/* 返回实际写入的总字节数，出错返回 -1 */
static ssize_t write_all(int fd, const void *buf, size_t len)
{
    const char *p = (const char *)buf;
    size_t done = 0;

    while (done < len) {
        ssize_t n = write(fd, p + done, len - done);
        if (n < 0) {
            if (errno == EINTR)
                continue;          /* 被信号打断，重试 */
            return -1;
        }
        if (n == 0)
            return -1;             /* 无法推进，避免死循环 */
        done += (size_t)n;
    }
    return (ssize_t)done;
}
```

两个细节值得说。一是对中断直接重试，不要当成失败抛给上层，否则一次无关信号就能让日志出现缺口。二是对返回零单独处理，否则循环可能永远转下去。

还有一处容易写错：偏移量要用已写字节数累加，不能用原始长度减。前者是绝对进度，后者在多次短写之后就对不上了。

| 写法 | 优点 | 代价 |
| --- | --- | --- |
| 不检查返回值 | 代码最短 | 静默丢数据，事后无迹可查 |
| 循环直到写完 | 覆盖所有短写 | 要单独处理中断与零返回 |
| 交给缓冲库 | 不用自己写 | 退出前必须显式刷缓冲 |

第三行是很多团队的选择，但它把责任转移了而不是消掉了：缓冲库替你处理短写，你仍然要处理「退出时刷不刷」。

## 写完了就等于落盘了吗？

不等于。手册紧接着还有一句，说的是「交接」和「落盘」的区别：

> A successful return from write() does not make any guarantee that data has been committed to disk.

意思是：写调用成功返回，不保证数据已经提交到磁盘。数据此时通常还在页缓存里，进程崩溃不影响它，但机器掉电或强制重启就可能丢。

所以「日志完整」需要两个条件同时成立：所有字节都交给了内核，并且内核把它们刷到了存储介质。前者靠循环写，后者靠同步刷盘或合适的挂载与刷盘策略。

对普通业务日志，多数人只保证前者，因为丢最后几百毫秒可以接受；对账务流水、审计记录这类不能丢的，两者都要，而且要在关键点显式刷一次。

这里有个顺序问题：先保证写完整，再谈刷盘。字节都没写全就去刷盘，刷出去的也是一份缺了尾巴的数据。

## 单次写有没有长度上限？

有。Linux 上单个写调用能提交的字节数有上限，大约是 2GB 减一页，也就是 0x7ffff000 这个量级。

| 参数 | 数量级 | 含义 |
| --- | --- | --- |
| 单次写上限 | 0x7ffff000 | 超出部分不会进内核，需自行续写 |
| 常见页大小 | 4096 | 上限按页对齐扣减 |
| 典型日志块 | 4KB 到 64KB | 远低于上限，通常不触发 |
| 批量导出块 | 数十 MB | 稳定但需检查返回值 |

如果你一次请求写 3GB，调用可能成功返回，但只提交了 2GB 左右。写大文件、导出大对象时容易碰上。

对我们这次故障，单次写都在几十 KB，上限不是主因。但它解释了另一个老现象：某些批量导出任务的日志总是断在同一个位置——那里正好是单块超过上限的分界点。

## 现场怎么确认是部分写？

最省事的办法是看系统调用。跟踪目标进程，过滤写相关的调用，比较请求长度与返回值：

```bash
# 只看写类调用，-s 控制显示长度，-f 跟进子进程
strace -f -e trace=write,pwrite64 -s 64 -p <pid>
# 返回值小于请求长度的那些行，就是证据
```

如果没有权限跟踪，退一步看三个地方：文件系统剩余空间与配额、进程的资源限制、以及信号处理方式。这三处能覆盖大部分短写场景。

还有一种情况要单独排除：日志框架自己把错误吞了。有些实现写失败只累加一个内部计数，不打任何日志，于是从应用层看就是「什么都没发生」。

跟踪之前有个小技巧：先找到进程持有的文件描述符编号，只过滤那一个，输出会干净很多，也不会把控制台的正常输出混进来。

## 这件事后来怎么固化的？

我们做了三件事：把落盘统一收敛到一个函数，返回值必须检查；在评审清单里加一条「所有写调用是否处理了短写」；在监控里加了「日志文件增长速率骤降」的告警。

这套排查记录一开始散在几次值班笔记里，后来用 AI墨衍 归拢成按「现象、验证命令、结论」三列排的表，新人值班时直接照着走。

写完那一版之后，同类问题在两个月里只又出现过一次，而且当场就定位到了具体调用。

## 哪些地方容易重复踩？

三类：自己封装的写文件函数、写网络套接字的发送逻辑、以及把大对象导出到本地文件的批处理任务。

它们的共同点是「一次调用就当完成」。把这层假设换掉，问题基本就没了。判断也很简单：全仓搜写调用，每一处都问一句返回值去哪了。

第二类尤其值得看。网络发送的短写比文件更常见，因为它还受对端接收窗口影响，同一份代码在压测环境和生产环境的表现可能完全不同。

## 常见问题

**问：返回值等于请求长度，还需要继续检查吗？**

答：这一步已经够了，短写已经排除了。要落盘就在关键点再刷一次，那是另一个动作。

**问：只写日志的话，用带缓冲的库不就不用管了？**

答：缓冲库内部也在处理短写，前提是它的实现正确。真正要管的是进程退出前的刷缓冲，以及写失败时你有没有感知。

**问：短写会不会被误判成磁盘故障？**

答：会。返回零加上磁盘满，看起来就像存储坏了。先看错误码，再看剩余空间，顺序别反。

## 小结

三句话：写调用成功不代表写完，返回值才是唯一依据；短写要按返回值循环续写，落盘要额外刷一次；单次写还有长度上限，大块数据必须分批。


线上日志偶尔会在某一条记录中间断开，后面的内容整段消失。文件大小正常，进程没退出，磁盘还剩一半空间，重启之后照样在同一类位置开始缺。

云服务器上的日志总缺最后几行，问题在 write 只写进去一部分

人工智能

线上日志末尾记录缺失，根因是写调用未检查返回值导致短写，加之退出时未刷新缓冲。判断写完成的唯一依据是返回值等于请求长度，而非无报错。需循环续写至完成，并区分写完整与落盘。单次写有约2GB上限，大块数据必须分批处理。排查用strace比较请求与返回长度，监控日志增长速率骤降可预警。

日志文件

文件系统

代码解释

Linux

4核4G3M云服务器 新用户低至38元/年！

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云服务器上的日志总缺最后几行，问题在 write 只写进去一部分-腾讯云开发者社区-腾讯云

云服务器上的日志总缺最后几行，问题在 write 只写进去一部分

云服务器上的日志总缺最后几行，问题在 write 只写进去一部分

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐