seth-shi

seth-shi

HomeArchives

Learnings from a case where Laradock scheduled tasks were not executed

#PHP#Laravel#Docker#Windows48
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
The lesson learned from a Laradock scheduled task not executing on Windows. Various troubleshooting steps were taken, including checking logs, adjusting permissions, and resolving line ending issues between Windows and Linux. Ultimately, the solution involved removing Laravel tasks from a Laradock file, rebuilding containers, and using the php-worker container to manage scheduled tasks successfully.
  • The laradock placed the scheduled task in the workspace container, so let's check the logs

  • docker-compose logs -f workspace
Jul  2 12:26:59 9b6ec4d18dd1 syslog-ng[12]: syslog-ng starting up; version='3.13.2'
workspace_1                               | *** Booting runit daemon...
workspace_1                               | *** Runit started as PID 20
workspace_1                               | Jul  2 12:27:00 9b6ec4d18dd1 cron[23]: (CRON) INFO (pidfile fd = 3)
workspace_1                               | Jul  2 12:27:00 9b6ec4d18dd1 cron[23]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
workspace_1                               | Jul  2 12:28:01 9b6ec4d18dd1 CRON[26]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:29:01 9b6ec4d18dd1 CRON[60]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:30:01 9b6ec4d18dd1 CRON[84]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:31:01 9b6ec4d18dd1 CRON[102]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:32:01 9b6ec4d18dd1 CRON[120]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:33:01 9b6ec4d18dd1 CRON[157]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:34:01 9b6ec4d18dd1 CRON[178]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:35:01 9b6ec4d18dd1 CRON[198]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
workspace_1                               | Jul  2 12:36:01 9b6ec4d18dd1 CRON[218]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1)
  • After checking the logs, the task is executing normally, so let's enter the container

docker-compose exec workspace bash

  • Run the scheduled task without suppressing the output
/usr/bin/php /var/www/artisan schedule:run
# If the timing is right, the scheduled task will be executed
# xxxx => xxx
  • The task is executing normally and the logs are being written correctly.
  • Exit the container and check the logs in /storage/logs, and we found the problem.
  • When entering the container directly, the default identity is root, so executing the task with log output will modify the log permissions, and creating directories will also cause this problem.
  • However, the laradock user is used to execute tasks in the workspace container, which causes it to not run properly.
**** * * laradock /usr/bin/php /var/www/artisan schedule:run >> /dev/null 2>&1
  • Let's set the permissions for all directories correctly first
chmod -R 0777 storage
  • Enter the container using the identity
docker-compose exec --user=laradock workspace bash

Updated on Friday, July 2, 2021 at 11:19:56#

  • Found that the scheduled task is not executing, ruled out the file permission issue mentioned above, and when entering the container as the laradock user, the command can be executed normally.
  • Check the logs output of the workspace container.
  • docker-compose logs -f --tail 100 workspace
  • Found the problem in the output (noticed an extra ^M after the scheduled task)
workspace_1         | Jul  2 03:19:01 fac0b255876a CRON[344]: (CRON) info (No MTA installed, discarding output)
workspace_1         | Jul  2 03:20:01 fac0b255876a CRON[350]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /de
v/null 2>&1^M)
workspace_1         | Jul  2 03:20:01 fac0b255876a CRON[348]: (CRON) info (No MTA installed, discarding output)
workspace_1         | Jul  2 03:21:01 fac0b255876a CRON[354]: (laradock) CMD (/usr/bin/php /var/www/artisan schedule:run >> /de
v/null 2>&1^M)
  • After researching, it was found that this is caused by the difference in line endings between Windows and Linux, which prevents Linux from recognizing it correctly and causing the scheduled task to not trigger.
  • Remove the extra characters, rebuild the container, and the task will run normally.

To prevent duplicate triggering of scheduled tasks in a multi-machine deployment of workspace#

  • Remove the Laravel task scheduling from the laradock/workspace/crontab/laradock file
  • Rebuild the container, then stop the old container and start the new one, do not restart directly
  • docker-compose build workspace
  • docker-compose stop workspace && docker-compose up -d workspace
  • Use the php-worker container to manage the scheduled tasks
  • Copy the file laravel-scheduler.conf.example and rename it to laravel-scheduler.conf
  • Then restart the php-worker container to load the new tasks
  • docker-compose restart php-worker
  • Check the task status inside the container
  • docker-compose exec php-worker sh
/etc/supervisor/conf.d # supervisorctl status
laravel-scheduler:laravel-scheduler_00   RUNNING   pid 9, uptime 2:14:33
  • The above output indicates that the scheduled task is running normally
Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.