你正盯着监控大屏，突然一串告警刷屏——服务器日志在疯狂报错，内核消息里全是一行让人摸不着头脑的提示：“12 bytes leftover”。
这到底是什么意思？是黑客入侵？硬件故障？还是Oracle数据库要出大事？今天咱们就来一场技术破案，看看怎么用审计工具，揪出那个让DBA和运维都头疼的“捣蛋鬼”——Oracle数据库自己。
一、案发现场：神秘的“12字节”幽灵
事情是这样的：最近刚接手一套数据库服务器的操作系统日志，告警就堆过来了。登录服务器一看，/var/log/messages正在疯狂刷屏，满屏都是同一行内核报错：
netlink: 12 bytes leftover after parsing attributes.
netlink: 12 bytes leftover after parsing attributes.
...
“netlink”是什么？“leftover”又是什么意思？
是网卡坏了？
有人在进行网络攻击？
还是Oracle数据库要崩了？
对于一套跑着关键业务的CentOS 6.5 + Oracle 11g环境来说，这种看不懂的报错最让人心慌。别急，咱们一步步来，把这个幕后黑手揪出来。
二、侦查工具：为什么常规手段失效？
遇到网络相关的内核报错，老手的第一反应通常是抓包。但在Linux内核的世界里，Netlink是一种特殊的通信机制，用于用户空间进程与内核空间的交互。普通的tcpdump抓不到它。我们需要更底层的工具——nlmon（Netlink Monitor）。
然而，在CentOS 6.5这种“古董级”系统上，执行modprobe nlmon却直接报错：
FATAL: Module nlmon not found.
路被堵死了？不，天无绝人之路。既然没有专门的监控模块，我们就用Linux自带的“天眼”——auditd（系统审计守护进程）。
它可以监控所有系统调用，不管你是TCP、UDP还是Netlink，只要动了系统资源，就休想逃过它的眼睛。
三、收网行动：锁定“嫌疑人”
我们迅速部署了审计规则，专门监控网络消息发送的系统调用sendmsg：
auditctl -a exit,always -F arch=b64 -S sendmsg -k netlink_debug命令执行后，静静地等待报错再次出现。几秒钟后，日志来了！
执行如下命令查看结果：
ausearch -k netlink_debug屏幕上跳出了关键的证据。在密密麻麻的十六进制代码中，两行信息格外刺眼：
type=SYSCALL ... comm="oracle" exe="/u01/app/oracle/product/11.2.0/db_1/bin/oracle" ...
真相大白！
- 嫌疑人：comm="oracle"
- 作案工具：/u01/app/oracle/product/11.2.0/db_1/bin/oracle
- 作案动机：Oracle进程正在试图通过Netlink协议向内核查询网络状态（可能是为了监听心跳或路由信息）。
四、案情分析：为什么自己人会报错？
抓到了“凶手”，但疑问更深了：为什么Oracle数据库会向内核发送错误的格式？这其实是一场“跨时代的误会”。
- Oracle 11g发布于2009年，是一个相当古老的版本。
- CentOS 6.5的内核（2.6.32）虽然也老，但相对于Oracle 11.2.0的编译环境来说，对Netlink协议的解析变得更加严格了。
简单来说，Oracle程序在发送数据时，按照旧标准多带了“12个字节的行李”（填充字节）。以前的内核比较宽容，直接放行了；但现在的内核比较严谨，看到多余的字节就忍不住吐槽：“你怎么还带多余的东西？解析不完啦！”
于是，内核一边处理了请求，一边在日志里留下了这句抱怨：12 bytes leftover。
五、结案陈词：虚惊一场
既然确认了是Oracle自身进程发出的，且是因为版本兼容性导致的格式不匹配，那么结论就很明确了：
这是一个“无害的噪音”。只要你的数据库没有出现连接中断、RAC心跳丢失或性能抖动，这个报错仅仅是在发泄内核的不满，并不会影响业务的正常运行。
检查完毕后的处理建议：
- 清理现场：别忘了关掉刚才开启的审计规则，否则磁盘很快会被撑爆。
auditctl -D
- 心态放平：在老旧系统上，这类“水土不服”很常见。如果业务稳定，无需强行升级数据库或内核。
- 后续优化：如果实在看着难受，可以尝试升级iproute包，有时候能解决部分系统工具引发的类似问题，但针对Oracle本体的报错，只能靠升级数据库版本彻底解决。
最后说两句：遇到看不懂的报错，别慌。善用auditd这样的底层工具，让数据说话。毕竟，在Linux的世界里，没有哪个进程能隐藏它的踪迹。
