Crontab编辑后变更异常：crontab -l显示旧内容但crontab -e显示正确

看起来你遇到了一个挺棘手的crontab同步问题——明明编辑保存后提示安装成功，crontab -e能看到新内容，可crontab -l却顽固地显示旧版本，而且之前的任务还正常运行了，确实挺让人困惑的。我来给你梳理几个常见的排查方向和解决办法：

先排查最容易犯的低级错误：用户身份混淆 #

很多人会在这里栽跟头：不同用户的crontab是完全独立的。比如你用普通用户编辑的crontab，和用sudo crontab -e编辑的root用户crontab是两个完全不同的文件。

你可以先确认当前终端的用户：

whoami

然后分别查看当前用户和root用户的crontab：

crontab -l          # 当前用户的crontab
sudo crontab -l     # root用户的crontab

看看是不是你编辑的是其中一个，却在查看另一个的内容。

直接检查crontab的实际存储文件 #

crontab的内容最终会存在系统的特定目录里，不同发行版路径略有不同：

• Debian/Ubuntu系：/var/spool/cron/crontabs/，每个用户的crontab文件就是用户名
• RHEL/CentOS系：/var/spool/cron/，同样以用户名命名

你可以直接查看这个文件的内容，对比和crontab -e里的是否一致：

# Ubuntu/Debian示例，替换成你的用户名
cat /var/spool/cron/crontabs/$(whoami)

如果这个文件里是你最新编辑的内容，但crontab -l还是旧的，那大概率是crond服务的缓存或者同步问题。

重启crond服务强制同步 #

有时候crond服务可能出现了同步延迟，重启一下就能解决：

# Ubuntu/Debian
sudo systemctl restart cron

# RHEL/CentOS
sudo service crond restart

重启后再运行crontab -l，看看内容是否更新了。

检查编辑器和保存操作是否正常 #

虽然你已经看到了“installing new crontab”的提示，但还是确认一下编辑时的操作：比如用vim的话，是不是用:wq正常保存退出的？有没有可能编辑器在保存时出现了异常（比如磁盘空间不足？不过这种情况会有报错提示）。

你可以再重新编辑一次，确保保存退出的步骤正确，然后立刻查看实际存储文件的内容，确认是否写入成功。

排查是否有其他进程自动修改crontab #

这种情况比较少见，但也有可能：比如系统里的某个脚本、配置管理工具（比如Ansible、SaltStack）在自动覆盖你的crontab内容。

你可以查看cron的系统日志，看看有没有异常的修改记录：

# Ubuntu/Debian
grep cron /var/log/syslog

# RHEL/CentOS
grep cron /var/log/cron

日志里会记录crontab的安装、修改操作，看看有没有你不知情的修改记录。

按照上面的步骤一步步排查，应该能找到问题所在。先从用户身份混淆这个最常见的情况开始，大概率能解决问题。

备注：内容来源于stack exchange，提问作者James T