Navicat计划任务依赖系统crond而非自身调度，其仅将任务写入crontab；若crond未运行（如显示inactive (dead)），任务将静默失败。需用systemctl启动并启用cron服务，且确保脚本使用绝对路径、正确环境变量及MTA配置。
Navicat计划任务依赖系统crond，不是它自己调度
navicat 的「计划任务」只是把任务写进 crontab，它本身不运行调度器。linux 下如果 crond 服务没启动，所有 navicat 创建的任务都会静默失败——连日志都不留。
- 检查状态：
systemctl status crond（CentOS/RHEL）或systemctl status cron（Ubuntu/Debian） - 若显示
inactive (dead)，执行：sudo systemctl start cron并sudo systemctl enable cron - Navicat 启动时不会提示你 crond 没开，也不会自动拉起它——它只管写，不管跑
crontab里任务存在，但没触发：环境和路径是主因
用 crontab -l 能看到任务，不代表它真能跑。cron 的执行环境极简：$PATH 基本只有 /usr/bin:/bin，不读 ~/.bashrc，也不继承 GUI 应用的环境变量。
- 脚本中所有命令必须用绝对路径，比如
/usr/bin/python3、/usr/bin/mysqldump，不能只写python3或mysqldump - 在
crontab -e文件顶部显式声明环境：PATH=/usr/local/bin:/usr/bin:/bin、HOME=/home/your_user - 给脚本加执行权限：
chmod +x /path/to/your/script.sh - 重定向输出查错：
0 2 * * * /path/to/script.sh >> /tmp/navicat_cron.log 2>&1
Navicat备份任务报“command not found”或空文件
这类错误几乎都指向 mysqldump 路径未配或版本不兼容。Navicat 不自带备份工具，全靠调系统命令，而 GUI 环境和 cron 环境的 $PATH 完全不同。
- 先手动验证：
mysqldump --version是否能执行；不能，说明没装或不在 cron 的PATH里 - Navicat 设置页中「备份工具路径」必须填绝对路径，例如：
/usr/bin/mysqldump（Ubuntu）、/opt/mysql/bin/mysqldump（自定义安装） - MySQL 8.0+ 默认用
caching_sha2_password插件，老版mysqldump不认——勾选 Navicat 备份设置里的「使用旧版身份验证」，等效于加参数--default-auth=mysql_native_password - 密码含
@、$等符号？启用 Navicat 的「转义密码」选项，否则命令行解析会截断
日志里有“Relay access denied”，邮件告警发不出
Navicat 发邮件不是走 SMTP 库，而是调系统命令如 sendmail、ssmtp。这些命令若没装、路径错、或 MTA 配置缺认证，就会卡在中继环节。
- 确认命令存在且可执行：
which sendmail或/usr/sbin/sendmail -V；Alpine、某些最小化系统默认不带 - Navicat「邮件设置」里的「发送命令」必须是绝对路径，比如
/usr/sbin/sendmail -t，相对路径在 cron 下必失败 -
Relay access denied表示 MTA 尝试转发时被拒，常见于没配账号密码或没启 STARTTLS - Postfix 用户需检查
/etc/postfix/sasl_passwd是否含目标 SMTP 凭据，并执行：postmap /etc/postfix/sasl_passwd+systemctl reload postfix - Gmail/Outlook 等需开启「应用专用密码」，普通密码会被两步验证拦截
真正容易被忽略的点是：Navicat 在 Linux 下创建的计划任务，完全脱离其 GUI 进程生命周期。哪怕你关掉 Navicat，只要 crond 在跑、脚本路径和权限无误、MTA 配置到位，任务照常执行。反过来，只要其中一环断在系统层（比如 crond 挂了、sendmail 被删、mysqldump 权限被改），GUI 界面不会报错，只会安静地不干活。
