最新文章專題視頻專題問答1問答10問答100問答1000問答2000關鍵字專題1關鍵字專題50關鍵字專題500關鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關鍵字專題關鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當前位置: 首頁 - 科技 - 知識百科 - 正文

crontab導致的頻繁發(fā)送郵件的問題

來源:懂視網 責編:小采 時間:2020-11-09 14:56:57
文檔

crontab導致的頻繁發(fā)送郵件的問題

crontab導致的頻繁發(fā)送郵件的問題:今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)送一次, 今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)
推薦度:
導讀crontab導致的頻繁發(fā)送郵件的問題:今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)送一次, 今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)

今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)送一次,

今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,,感覺是1個小時發(fā)送一次,完全可以3個小時發(fā)送一次,接到這個問題后,最直接的聯(lián)想就是使用crontab。
結果登錄到服務器端之后查看,得到的結果如下:
> crontab -l
# Minute Hour Month Day Month Weekday Command
###############################################################################
52 6,9,12,15,18,21 * * * /oravl01/orainst/XXXXX/FileSystem.ksh
################### TABLESPACE ALERT - FOR ALL ######################################
52 6,9,12,15,18,21 * * * /bin/ksh "/oravl01/orainst/dba/ENV/free_tbs_alert.ksh XXXX"
簡單再來回顧一下crontab的使用,crontab中含有6個參數(shù),分別代表分,小時,天,周,月,待運行的腳本。
所以對于這個問題來說,
52 6,9,12,15,18,21 * * * 代表的意義就是 在每天的6點,9點,12點,15點,18點,21點,在52分的時候運行一次指定的腳本內容。
按照這個配置還是很合理的,在大半夜也不會頻繁發(fā)送不是很緊急的一些郵件造成不必要的干擾。從配置來看是每3個小時運行一次。
但是根據(jù)客戶的反饋說發(fā)送的頻率有些頻繁了,在這一點上,問題就有些蹊蹺了。
帶著疑問查看了對應的腳本內容,也沒有發(fā)現(xiàn)特別的時間設定,都是一些例行的檢查點。
最后帶著疑惑和客戶做了簡單的溝通,根據(jù)目前的配置確實是3個小時,如果在3個小時以內,應該是出現(xiàn)了什么問題,可以把郵件轉給我??蛻舻姆答佉埠芸?,他們給我轉來了最新的郵件,發(fā)現(xiàn)兩封基本相同的郵件,時間點很近,一個是52分的時候,這個和crontab里面的配置是吻合的,另外一個是在0分的時候發(fā)送的。對于這點就有些疑惑了。帶著疑問排除了本地的crontab的配置問題,開始在相關的環(huán)境中查找,因為有了方向查找起來不算太費勁,終于在一個環(huán)境中使用crontab -l找到了類似的配置。
### TRAINING ENVIRONMENT- DB SERVER FS ALERT REPORT ###
00 6,9,12,15,18,21 * * * ssh orainst@XXXX '/bin/ksh /oravl01/orainst/XXXX/FileSystem.ksh'

### TRAINING ENVIRONMENT- DB SERVER TABLE SPACE ALERT REPORT ###
00 6,9,12,15,18,21 * * * ssh orainst@XXXX '/bin/ksh /oravl01/orainst/dba/ENV/free_tbs_alert.ksh XXXXX'
這個配置的意思就是在每天的6點,9點,12點,15點,18點,21點,在0分的時候開始運行腳本并發(fā)送相應的郵件。
明白了這點問題的處理就很簡單了,現(xiàn)在需要弄明白的是為什么這個crontab需要在其它服務器中配置而不是本地。如果需要禁用,改禁用哪個。
做了簡單的溝通,最后明白,原來這里他們使用的另外一臺服務器是一個類似代理的角色,其中配置著大量的crontab的設置,通過這個客戶端能夠控制各個服務端的一些數(shù)據(jù)運行情況,按照最初的約定,是3個小時運行一次腳本,做一次相應的檢查工作。
那么為什么服務端又莫名其妙的啟用了crontab設置呢,最后發(fā)現(xiàn)是在上周五的時候有個DBA做了一個crontab的測試,結果沒有注意到已經在后臺統(tǒng)一配置了,簡單做了禁用問題就修復了。
這個簡單的案例我們可以發(fā)現(xiàn),很多蹊蹺的問題都是事出有因,如果去追查根本的原因,不是一些配置問題就是一些相關的協(xié)調不一致導致的問題。這類問題的處理方式還是建立統(tǒng)一的標準和權限,就能夠在一定程度上規(guī)避類似的問題了,說起來容易做起來難,還是需要慢慢改進了。

Linux中利用crontab創(chuàng)建計劃任務

Linux中用crontab例行工作安排

Linux crontab不執(zhí)行問題排查

Ubuntu使用crontab定時任務

Linux計劃任務(at batch crontab anacron)

本文永久更新鏈接地址:

聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文檔

crontab導致的頻繁發(fā)送郵件的問題

crontab導致的頻繁發(fā)送郵件的問題:今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)送一次, 今天下午的時候客戶發(fā)郵件反饋說,對于某個環(huán)境中的文件系統(tǒng)監(jiān)控和表空間使用情況的郵件收到的比較頻繁,感覺是1個小時發(fā)
推薦度:
  • 熱門焦點

最新推薦

猜你喜歡

熱門推薦

專題
Top