解决clientmqueue中产生巨量文件导致DNS服务器不可达故障

发生

周五上午一早,多台服务器产生 DNS-1服务不可达告警。登陆到服务器上ping DNS服务器地址正常,使用nslookup指定故障DNS服务器查询域名也是正常。尝试重启DNS-1服务器后,故障短暂恢复,过了30分钟又出现告警。同时多台服务器又同时产生 DNS-3、DNS-4服务不可达告警。

处理

查看DNS服务器上的CPU、内存占用均无问题,但查询硬盘使用情况发现,4台服务器中的三台根分区占用率已经达到100%

[root@DNSsrv1 /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              20G   20G    0M 100% /
/dev/sda4             109G  320M  103G   1% /home
/dev/sda1             996M   67M  878M   8% /boot
tmpfs                  12G     0   12G   0% /dev/shm

于是先将占用空间较大的log文件备份出来,腾出一些空间,以恢复服务的正常运行。同时使用 du -h --max-depth=1 /* 排查占用空间较大的文件位置。经检查发现, /var/spool/clientmqueue/ 目录占用了巨量的磁盘空间,在该目录下 ls 会造成终端卡死。

/var/spool/clientmqueue/ 目录为存放linux系统内mail的缓存文件夹。当有系统事件或cron定时任务具有输出时,系统会调用sendmail服务为用户发送信件。如果系统中有sendmail服务运行的话,信件将会存放到/var/spool/mail/中对应的用户名文件内。若sendmail服务并没有运行,信件则会存放到 /var/spool/clientmqueue/ 内。

使用crontab -l检查定时任务脚本,并未发现有输出的脚本。对所有定时任务脚本加入了>/dev/null 2>&1重定向所有输出到/dev/null防止定时任务产生信件。

由于 /var/spool/clientmqueue/ 中的文件太多,无法使用 rm -f *直接删除,需要使用 ls | xargs rm -f 进行删除。耗时三个小时将 /var/spool/clientmqueue/ 中的文件清空,清理了15G的文件。

[root@DNSsrv1 /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              20G  3.9G   15G  22% /
/dev/sda4             109G  320M  103G   1% /home
/dev/sda1             996M   67M  878M   8% /boot
tmpfs                  12G     0   12G   0% /dev/shm

观察该文件夹,仍然在每五分钟产生15个新的文件

 

查看其中信件内容为

From root@DNSsrv1  Sat Apr 29 11:15:43 2017
Return-Path: <root@DNSsrv1>
Received: from DNSsrv1 (dnsserver [127.0.0.1])
        by DNSsrv1 (8.13.8/8.13.8) with ESMTP id v3T3CGvN014948
        for <root@DNSsrv1>; Sat, 29 Apr 2017 11:15:42 +0800
Received: (from root@localhost)
        by DNSsrv1 (8.13.8/8.13.8/Submit) id v3SKjM7U019884;
        Sat, 29 Apr 2017 04:45:22 +0800
Date: Sat, 29 Apr 2017 04:45:22 +0800
Message-Id: <201704282045.v3SKjM7U019884@DNSsrv1>
To: root@DNSsrv1
From: ituser@DNSsrv1
Auto-Submitted: auto-generated
Subject: *** SECURITY information for DNSsrv1 ***

DNSsrv1 : Apr 29 04:45:22 : ituser : /etc/sudoers is mode 0755, should be 0440 ; TTY=pts/0 ; PWD=/home/ituser ; USER=root ; COMMAND=/usr/sbin/ethtool eth6

原来是由于 /etc/sudoers 文件权限不是0440而导致每次sudoer用户ituser执行sudo命令的时候,sudo通知root用户该文件权限不对。

使用 chmod 0440 /etc/sudoers 修改文件权限后,再没有新的文件产生了。

总结

  1. 例行查看服务器状态时多留意磁盘空间的变化
  2. 使用cron执行定时任务脚本时,要注意脚本的输出,若不想收到Linux系统信件,记得将输出重定向到/dev/null
  3. 为防止类似事情发生,可设置定时任务定时清除/var/spool/clientmqueue/中的文件



作者:康悦
链接:https://www.jianshu.com/p/8fb763c6ba39
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。

### Android 巨量广告 SDK 数据上传失败解决方案 #### 1. 检查网络连接状态 确保设备具有稳定的互联网连接。可以尝试在网络设置中切换Wi-Fi或移动数据来测试是否能解决问题。如果是在模拟器上运行,则需确认模拟器的网络配置正确[^2]。 #### 2. 验证权限声明 仔细检查`AndroidManifest.xml`文件中的权限声明,特别是涉及到存储、位置服务以及访问网络的相关权限。缺少必要的权限可能导致SDK无法正常工作。对于巨量引擎广告SDK而言,通常至少需要以下权限: ```xml <uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> ``` #### 3. 更新至最新版本 保持使用的SDK为最新的稳定版本非常重要。旧版本可能存在已知缺陷影响性能表现。建议定期查看官方文档获取更新日志并及时升级到新版本[^1]。 #### 4. 审核初始化参数 在应用程序启动时调用初始化方法传递给SDK的各项参数应当准确无误。任何不匹配的应用包名或其他标识符都会阻碍后续操作的成功执行。具体来说,在初始化过程中应提供正确的App ID和其他必要信息[^3]。 #### 5. 日志分析与调试工具利用 启用详细的日志记录有助于定位潜在问题所在。通过阅读控制台输出的日志消息能够发现更多关于为什么会出现数据传输障碍的信息。此外,还可以借助ADB命令行工具抓取更深层次的日志以便进一步排查原因。 ```bash adb logcat *:V | grep "Pangle" ``` 此命令会过滤出所有来自Pangle库的日志条目,方便追踪异常情况。 #### 6. 测试环境验证 创建一个干净的新项目专门用于测试目的,排除其他因素干扰的情况下单独检验SDK的功能性。这样可以帮助判断问题是特定于现有项目的某些配置还是普遍存在于所有环境中。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值