你遇到的这个问题其实挺典型的，我来给你拆解下核心原因：

首先先还原下你的场景：
你配置了一条crontab定时任务来执行重载Nginx的脚本：

11 11 * * * /root/change.sh >> /root/script.log

脚本里用了service nginx reload来重载服务，但发现syslog里显示脚本已经执行，可Nginx配置根本没重载，服务日志也没新记录；换成systemctl reload nginx后就一切正常了。

问题的根源在于**service命令和systemctl命令的执行逻辑、对环境的依赖完全不同**：

• service是一个老式的兼容性封装脚本，它的设计目的是适配不同的初始化系统（比如早年的SysVinit、后来的Upstart，还有现在主流的systemd）。它会先检测当前系统用的是哪种init系统，再去调用对应的管理命令。但crontab的执行环境非常受限：它的PATH环境变量只包含最基础的几个系统目录（比如/bin、/usr/bin），不像你登录到shell里时PATH会包含更多路径。这就导致service脚本可能找不到它需要的依赖文件，或者无法正确定位到systemd的执行入口，最终默默执行失败——而你的crontab只重定向了标准输出到日志，错误输出没被记录，所以你看不到失败原因。
• systemctl是systemd原生的服务管理命令，它的执行路径（一般是/usr/bin/systemctl）通常在crontab的默认PATH里，能被直接找到。而且它直接和systemd进程通信，不需要中间的兼容适配层，执行逻辑更直接，不容易因为环境变量缺失出问题。

你可以做个小验证：把脚本里的service nginx reload改成绝对路径的形式（比如/usr/sbin/service nginx reload），或者在crontab里给任务加上完整的PATH配置，大概率也能正常执行——这就能侧面印证是环境变量的问题导致service命令没正常工作。

另外还有个小细节：你的crontab任务只重定向了标准输出>> /root/script.log，建议改成>> /root/script.log 2>&1，这样错误输出也会被记录下来，下次遇到类似问题就能直接在日志里看到失败原因了。

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