Solaris系统cron服务异常解决记录

自从公司政策变化，将服务器转到部门后，像我这种小白总会遇到各种各样维护的问题，这不，最近两月发现NIS服务工作异常，不能实时同步远端LDAP数据了。由于NIS和DNS服务器系统是古老的SunOS 5.10，谁用谁知道，我是真的不喜欢啊~开始比较懒，请IT帮忙，但各种推诿，一个月过去问题还在，心里万千只草泥马奔腾，好吧，无奈之下只能自己硬着头皮上了。

本文记叙了解决问题的整个过程，比较啰嗦，如果您只想看问题是如何解决的，请直接跳转到本文末尾的第4节查看总结。

以下是我解决这个问题的大致过程。

1. 检查同步设置

NIS服务器上的数据每15分钟更新一次，所以肯定使用了cron服务。

啰嗦一句，Solaris下crontab文件放在

/var/spool/cron/crontabs

目录下：

# cd /var/spool/cron/crontabs
# ls -lh
total 14
-rw-------   1 root     sys          190 Nov 10  2006 adm
-r--------   1 root     root         452 Jan 22  2005 lp
-rw-------   1 root     root        2.0K Aug 24 15:17 root
-rw-------   1 root     sys          308 Nov 10  2006 sys
-r--------   1 root     sys          404 Feb 14  2007 uucp

有两种方法查看crontab文件的内容：

- 第一种，用编辑器直接打开

/var/spool/cron/crontabs

目录下相应的文件查看

- 第二种，使用命令

crontab -l [username]

查看，这里的username指定了要为其显示crontab文件的用户账户名称，不带username会显示当前用户缺省的crontab文件内容（如当前是root用户，则显示root文件的内容）。

以下是以root身份查看crontab的内容：

# crontab -l
# HEADER: This file was autogenerated at Thu Jul 24 08:23:09 +0800 2014 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
#ident  "@(#)root       1.21    04/03/23 SMI"
#
# The root crontab should be used to perform accounting data collection.
#
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
#

...

# L2N
# 2,17,32,47 * * * * /var/yp/etc/L2N/L2N_group > /tmp/L2N_group.log 2>&1
#
# NAC Error messages
59 23 * * * /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen 2>&1 | /bin/mailx -s 'Shenzhen NAC error messages of the day' it-she-filers-list@guyongqiangx.com
#
# l2n_ng 'make passwd' 5x per-hour
6,18,30,42,54 * * * * (cd /var/yp/etc; /usr/ccs/bin/make passwd > /tmp/l2n_ng.log 2>&1)
#

说实话，我开始是真不知道是为什么不能同步~求爷爷告奶奶的找人帮忙检查NIS同步设置，在同事的提示之下，以下用于从远端同步LDAP数据下载passwd的内容被注释了：

# L2N
# 2,17,32,47 * * * * /var/yp/etc/L2N/L2N_group > /tmp/L2N_group.log 2>&1

以下内容用于从同步的passwd内容更新NIS服务数据：

# l2n_ng 'make passwd' 5x per-hour
6,18,30,42,54 * * * * (cd /var/yp/etc; /usr/ccs/bin/make passwd > /tmp/l2n_ng.log 2>&1)

检查完，果然是同步任务被注释了，不知道是哪个搞的鬼~真缺德！果断的编辑crontab文件将数据同步数据打开。

编辑cron内容也有个小波折。

在命令行输入

crontab -e

，除了下面冒出来一串不知道是什么东西的数字，毛反应都没有啊~

像这样：

# crontab -e

2090

鸟哥的书上明明是说这样可以编辑crontab文件的，到底是什么情况！！！

度娘加Solaris系统管理指南里面都提到，想要在Solaris上编辑crontab，需要先设置EDITOR：

# which $EDITOR

#

# EDITOR=vi

# export EDITOR

#

# which $EDITOR

/usr/bin/vi

原来默认需要EDITOR变量来指定crontab的编辑器，默认EDITOR没有设置，设置完EDITOR，终于可以通过

crontab -e

来修改了。

修改完，仍然不能同步啊，瞬间想死的心都有了。

2. 转机，手动更新成功

绝望之下，自己尝试在命令行输入crontab中NIS数据同步的命令进行手动更新，天呐噜，竟然成功了~

希望来了，手动成功说明同步更新的功能是正常的，那问题就出在cron服务了。

3. 检查并修复cron服务

3.1 检查日志

默认cron服务的日志位于：

/var/cron/log

，进去一看，惊呆了，日志竟然有200M+：

# ls -lh /var/cron/
total 526230
...
-rw-------   1 root     root        218M Aug 25 17:30 log
...

那就找最近的日志看看：

# tail /var/cron/log
! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017
! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017
! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017
! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017
! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017
#

压根不知道发生了什么事，度娘了一下”

c queue max run limit reached

“，我靠，说cron队列满了~~~

3.2 查找cron失败原因

根据cron的PID使用ptree检查相关进程：

# ps -ef | grep cron
root   317     1   0   Oct 01 ?           3:25 /usr/sbin/cron
root  4586  4572   0 14:56:45 pts/4       0:00 grep cron
#
# ptree 317
317   /usr/sbin/cron
949   sh -c /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen 2>&1 | /bin/mailx
950   /bin/mailx -s Shenzhen NAC error messages of the day it-she-filers-list@guyongqiangx
951   /usr/local/bin/perl -T /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen
1878  sh -c /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen 2>&1 | /bin/mailx
1879  /bin/mailx -s Shenzhen NAC error messages of the day it-she-filers-list@guyongqiangx
1880  /usr/local/bin/perl -T /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen
2871  sh -c /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen 2>&1 | /bin/mailx
2872  /bin/mailx -s Shenzhen NAC error messages of the day it-she-filers-list@guyongqiangx
2873  /usr/local/bin/perl -T /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen
...
#
# top
load averages:  0.05,  0.07,  0.04;                    up 327+13:54:24                                     15:33:13
310 processes: 309 sleeping, 1 on cpu
CPU states:     % idle,     % user,     % kernel,     % iowait,     % swap
Memory: 4091M phys mem, 2901M free mem, 38G swap, 38G free swap

PID USERNAME LWP PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
9663 root       7  59    0 9176K 6848K sleep  369:18  0.00% named
11148 root       2  59    0 5984K 3508K sleep   31:20  0.00% automountd
271 root       1  59    0 5464K 1996K sleep   25:11  0.00% ypserv
398 root      15  59    0 4996K 3156K sleep   19:02  0.00% syslogd
420 root       1  59    0    0K    0K sleep   12:47  0.00% snmpd
421 root       1  59    0 6928K 3104K sleep    7:45  0.00% httpd
9 root      15  59    0   10M 9340K sleep    5:32  0.00% svc.configd
317 root       1  59    0 2548K 1336K sleep    3:24  0.00% cron
7 root      13  59    0   10M 9184K sleep    2:27  0.00% svc.startd
21473 root      30  59    0 5068K 4228K sleep    2:21  0.00% nscd
417 root      15  59    0   13M 9064K sleep    2:19  0.00% fmd
589 root       1  59    0 2132K 1480K sleep    1:41  0.00% master
237 daemon     1  59    0 2676K 1356K sleep    1:24  0.00% rpcbind
1 root       1  59    0 2156K 1052K sleep    0:33  0.00% init
CPU states: 99.9% idle,  0.0% user,  0.1% kernel,  0.0% iowait,  0.0% swap
Memory: 4091M phys mem, 2901M free mem, 38G swap, 38G free swap
#

ptree命令中出现了一大堆执行任务

sh -c /tools/logs/filers/bin/chk.nac.messages.pl -s shenzhen 2>&1 ...

的进程，top命令显示当前竟然有310个进程。

进一步检查脚本“

chk.nac.messages.pl

”执行的命令，确实是失败挂起了。

看来根源是cron执行脚本中“

chk.nac.messages.pl

”相应的任务挂起没有返回，然后每次调用cron就生成一个进程，直到最后cron的队列满了无法再创建工作队列执行任务。

3.3 修复任务

修改crontab脚本，暂时不再执行“

chk.nac.messages.pl

”，这还没完，因为cron队列满了，所以kill所有

chk.nac.messages.pl

相关任务，重启cron服务，一切又恢复如初了。

修改crontab脚本时，觉得修改完肯定要重启cron服务才行，网上找了半天，一句也没提到如何在Solaris下重启cron服务，无奈之下，直接将cron进程kill了，再次检查cron进程，发现系统自动生成了一个，这个好，不用想法如何重启了。

4. 总结

说了一大篇废话，以下是解决步骤的总结：

1. 在确认同步设置正确的情况下，手动尝试同步数据成功，说明问题出在cron服务上；

2. 检查cron服务日志文件

/var/cron/log

，定位到文件末尾，发现大量日志信息：

! c queue max run limit reached Thu Aug 24 14:56:00 2017
! rescheduling a cron job Thu Aug 24 14:56:00 2017

根据日志信息进行百度，发现cron队列满了

用ptree命令查找cron服务相关进程，发现

chk.nac.messages.pl

脚本相关的任务特别多

手动检查

chk.nac.messages.pl

任务的执行，发现进程挂起来了。因此根源是cron在其队列中不断定时创建这个任务，但任务不会结束，导致cron队列里的任务越来越多，最后队列满了无法再启动新的任务

取消失败任务，杀死cron队列中的挂起进程，cron服务正常运作。

5. 官方Solaris管理手册系列

最后，对于Solaris新手，果断献上官方的Solaris管理手册系列：

- 《Solaris系统管理指南：基本管理》

- 《Solaris系统管理指南：高级管理》

- 《Solaris系统管理指南：安全性服务》

- 《Solaris系统管理指南：网络服务》

- 《Solaris系统管理指南：IP服务》

- 《Solaris系统管理指南：命名和目录服务（DNS、NIS和LDAP）》

- 《Solaris系统管理指南：Naming and Directory Services (NIS+) 》