自從公司政策變化，將伺服器轉到部門後，像我這種小白總會遇到各種各樣維護的問題，這不，最近兩月發現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' [email protected]
#
# 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 [email protected]
      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 [email protected]
      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 [email protected]
      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

1. 根據日誌資訊進行百度，發現cron佇列滿了
2. 用ptree命令查詢cron服務相關程序，發現chk.nac.messages.pl指令碼相關的任務特別多
3. 手動檢查chk.nac.messages.pl任務的執行，發現程序掛起來了。因此根源是cron在其佇列中不斷定時建立這個任務，但任務不會結束，導致cron佇列裡的任務越來越多，最後佇列滿了無法再啟動新的任務
4. 取消失敗任務，殺死cron佇列中的掛起程序，cron服務正常運作。

5. 官方Solaris管理手冊系列