起因是一件詭異的事情，Linux服務器上的cron意外消失了，查看了操作日志，並沒有對cron進行編輯的命令出現。
大多是sudo crontab -l，或者不小心敲錯了的sudo crond，sudo crontab...
等等，好像有不對的地方，不小心敲下 crontab 之后，會好長時間沒有反應，我懶得等待，就強制退出了。
然后渡過了一個漫長的假期，回到公司，登錄Linux，敲下 crontab -l，然后，發現所有的任務竟然沒有了。。。
一開始我以為是命令敲錯了，就連着敲了多次，這才確認是真的被意外清空了。
ok，問題到這里結束。原因解析：
如果我們在SSH遠程終端中敲下“crontab”命令之后，遠程連接被一些原因（比如強制退出， 糟糕的網絡，程序異常）意外終止了，那么Crontab計划任務就會被操作系統所清空。
聽起來很不可思議，但是經過虛擬機上的多次測試，它確確實實的發生了。
測試方式為 用SecureCRT開一個SSH窗口，然后敲下命令“crontab”，接着在“任務管理器”中直接殺掉SecureCRT進程，再通過另外一個SSH窗口執行“crontab -l”，就會發現，所有的計划任務都不存在了。
補救措施：
短期內可以通過查看crontab日志文件 /var/log/cron 進行恢復。
crontab日志操作記錄分析：
進入 /var/spool/cron 目錄，輸入 history 命令回車查看，可判斷是否曾經單獨輸入了 crontab，且沒有加任何后綴參數。
cron執行日志分析：
執行 cat /var/log/cron 命令，如果正常執行的日志后面出現了類似 如下的日志記錄，那說明十有八九是crontab導致的了。
Oct 8 14:39:45 s1 crontab[30072]: (root) REPLACE (root)
Oct 8 14:40:01 s1 crond[13605]: (root) RELOAD (/var/spool/cron/root)
Oct 8 14:40:01 s1 CROND[15313]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)
Oct 8 14:40:01 s1 crond[5342]: (root) RELOAD (/var/spool/cron/root)
Oct 8 14:40:01 s1 CROND[15315]: (root) CMD (/usr/lib64/sa/sa1 -S DISK 1 1)