揪出元兇:linux定時(shí)任務(wù)crontab居然沒執(zhí)行
本文能學(xué)到
?如何判斷文件差異
?cron 對(duì)任務(wù)計(jì)劃文件要求
1. 背景
2. 初步排查
3. 分析
- crontab file格式不正確
- 文件系統(tǒng)被改寫
- crontab file所屬用戶不合法
3.1. x11 crontab file 格式不正確
- 1.備份配置文件 cp var/spool/cron/crontabs/root var/spool/cron/crontabs/root.bak;
- 2.執(zhí)行crontab -e;
- 3.cron任務(wù)計(jì)劃是否被執(zhí)行,需查看記錄 watch -n 1 cat /var/log/message。
- 4.計(jì)算兩文件md5是否一致 md5sum var/spool/cron/crontabs/root var/spool/cron/crontabs/root.bak;
證明:“crontab file 格式不正確”不是誘因。
3.2. x12 文件系統(tǒng)被改寫
crontab -e雖然沒有修改var/spool/cron/crontabs/root,但無法證明它有沒有改寫文件系統(tǒng)其他文件。于是在一塊重新燒錄鏡像的板卡執(zhí)行如下步驟排查:- 獲取文件系統(tǒng)所有文件的MD5保存為/tmp/a.txt;
find arch bin etc home lib media opt \root sbin tmp usr var -name "*" | \xargs md5sum > /unuse/a.txt
- 執(zhí)行crontab -e;
- 獲取文件系統(tǒng)所有文件的MD5保存為/tmp/b.txt;
find arch bin etc home lib media opt \root sbin tmp usr var -name "*" | \xargs md5sum > /unuse/b.txt
- 比較a.txt和b.txt是否一致,從而證明crontab -e是否修改文件系統(tǒng)內(nèi)容
證明:“x12 文件系統(tǒng)被改寫”不是誘因。
3.3. x13 crontab file所屬用戶不合法
產(chǎn)品的cron是busybox的組件,源碼面前無秘密。開始跟蹤crond執(zhí)行過程。在busybox源碼的miscutils/crond.c添加若干 “printf(”LINE %d", __ LINE __);"跟蹤程序運(yùn)行。 cron在前臺(tái)運(yùn)行,執(zhí)行crond -f var/spool/cron/crontabs/root; 發(fā)現(xiàn)947行沒有被執(zhí)行,且文件指針是0; 推斷:var/spool/cron/crontabs/root沒有被讀取。 跟蹤文件讀取函數(shù)load_crontab發(fā)現(xiàn)438行的if第二個(gè)條件不滿足,DEAMON_UID是0,只有當(dāng)sbuf.st_uid也等于0時(shí)才能執(zhí)行文件讀取,實(shí)際返回1000。變量sbuf.st_uid表示文件所屬用戶的UID。
- ?修改crontab file文件的UID和GID都是0,chown 0:0 /var/spool/cron/crontabs/root;
- ?重新啟動(dòng)crond:crond -f var/spool/cron/crontabs/
- ?10min后在/var/log/message里看到任務(wù)計(jì)劃執(zhí)行痕跡
Jan 10 12:00:00 (none) cron.info crond[854]: USER root pid 3506 cmd /usr/bin/compresslog.shJan 10 12:00:00 (none) cron.info crond[854]: USER root pid 3508 cmd /usr/local/bin/recode_check.shJan 10 12:10:00 (none) cron.info crond[854]: USER root pid 5007 cmd /usr/local/bin/recode_check.shJan 10 12:20:00 (none) cron.info crond[854]: USER root pid 6506 cmd /usr/local/bin/recode_check.sh結(jié)果:修改“crontab file所屬用戶”有效,任務(wù)計(jì)劃可以正常運(yùn)行。
證明:“crontab file所屬用戶不合法”是誘因
4. 推斷過程
看到這個(gè)1000我已經(jīng)覺察到問題根本原因,看我娓娓道來。 /etc/passwd記錄linux用戶所屬UID、GID。UID=0、GID=0屬于root用戶。passwd有若干ID號(hào),普通預(yù)設(shè)的用戶的UID、GID在1~999,adduser創(chuàng)建的用戶ID從1000開始,啟動(dòng)crond守護(hù)進(jìn)程時(shí)會(huì)根據(jù)當(dāng)前用名去 /var/spool/cron/crontabs/ 目錄下尋找與用戶名同名的文件,順帶檢查該文件的所屬用戶UID,只有文件存在、UID相同才讀取該文件。 按照設(shè)想,那么crontab -e執(zhí)行后應(yīng)該會(huì)修改用戶所屬ID,下面是實(shí)驗(yàn)步驟。- 再修改用戶組為 1000 “chown 1000:root /var/spool/cron/crontabs/root”
- 觀察crontab -e執(zhí)行前后文件所屬用戶是否改變
- 實(shí)踐和設(shè)想一致:crontab會(huì)修改文件所屬用戶。
5. 為什么測(cè)試階段沒發(fā)現(xiàn)問題
我的Linux系統(tǒng)開發(fā)環(huán)境普通用戶編碼從1000開始,為避免使用root用戶誤操作危害開發(fā)環(huán)境,一切文件均在普通用戶環(huán)境下編輯,為有編輯權(quán)限,曾執(zhí)行過 chown up /var/spool/cron/crontabs/root(不理解cron設(shè)計(jì)者為什么要去檢查文件所屬UID,即使當(dāng)前已經(jīng)是root權(quán)限),這個(gè)up就是我的用戶名,up的UID=1000。 之所以在軟件測(cè)試階段未發(fā)現(xiàn)問題,原因在于任務(wù)計(jì)劃默認(rèn)10min才執(zhí)行一次,為縮短測(cè)試時(shí)間而修改任務(wù)計(jì)劃執(zhí)行頻率,提高測(cè)試效率,修改方法就是crontab -e編輯/var/spool/cron/crontabs/root。
當(dāng)初只注重recode_check.sh執(zhí)行的正確性。
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!