laravel 12任务调度不支持开机自启,本质是依赖系统cron每分钟触发schedule:run命令;需确保cron服务开机自启,并以运行项目的用户(如www-data)在crontab中添加对应执行行。

Laravel 12 的任务调度本身**不直接支持“开机自启”**,因为它依赖的是外部定时触发机制——不是服务进程,而是一条每分钟运行的 schedule:run 命令。所以“让 Laravel 调度开机自启”的本质,是**确保系统 Cron 守护进程(cron 或 crond)开机自动运行,并且你的 crontab 条目已正确写入**。
确保系统 Cron 服务开机自启
这是前提,没有它,schedule:run 根本不会被调用。
- Ubuntu/Debian:
sudo systemctl enable cron
sudo systemctl start cron - CentOS/RHEL/AlmaLinux:
sudo systemctl enable crond
sudo systemctl start crond
验证是否生效:
sudo systemctl is-enabled cron(或 crond)应返回 enabled;
sudo systemctl status cron 应显示 active (running)。
把调度命令写进用户级 crontab
不是写进 /etc/crontab,而是用当前运行 Laravel 的用户(如 www-data、nginx 或部署用户)执行 crontab -e,添加这一行:
* * * * * cd /var/www/myapp && php artisan schedule:run >> /dev/null 2>&1
在无 root/sudo 权限的环境(云容器、VPS、隔离主机)中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景:...
注意:
• 替换 /var/www/myapp 为你的实际项目绝对路径;
• 确保该用户对项目目录有读写权限,且能执行 php;
• 不要用 sudo crontab -e,否则命令会以 root 身份运行,可能引发权限或环境变量问题。
别混淆:不是启动 Laravel 进程,而是启动调度“触发器”
Laravel 调度不是常驻后台的服务(像 schedule:work 那样),它靠的是“被动触发 + 主动检查”。
• schedule:run 是一个瞬时命令,执行完就退出;
• 真正的“调度逻辑”在 PHP 代码里(app/Console/Kernel.php),由这条 cron 每分钟拉起一次来判断该跑什么;
• 所以你不需要、也不应该用 systemd 去守护 schedule:run —— 它本来就不是长期进程。
特殊情况:想用 schedule:work(需 systemd 守护)
如果你明确选择 schedule:work(毫秒级精度、避免 Cron 1 分钟延迟),那它才是一个需要长期运行的 Artisan 进程,此时才需 systemd 自启:
- 创建
/etc/systemd/system/laravel-schedule.service:
[Unit]
Description=Laravel Schedule Worker
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/php /var/www/myapp/artisan schedule:work
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
- 启用:
sudo systemctl daemon-reload
sudo systemctl enable laravel-schedule
sudo systemctl start laravel-schedule
但注意:这属于进阶替代方案,标准生产环境仍推荐 schedule:run + 系统 cron,更轻量、更符合 Laravel 设计初衷。










