seth-shi

seth-shi

HomeArchives

Learnings from a case where Laradock scheduled tasks were not being executed

#PHP#Laravel#Docker#Windows40
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
Lessons learned from a Laradock scheduled task not running on Windows. The task was placed in the workspace container, logs were checked, and the task was found to be running normally. The issue was related to file permissions and line endings between Windows and Linux. The solution involved removing extra characters, rebuilding the container, and managing the task with the php-worker container.
  • 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, and executing tasks with log output will modify the log permissions. This problem also occurs if there are tasks that create directories.
  • However, the tasks in the workspace container are executed using the laradock user, which causes the tasks 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 at the end of 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 causes Linux to not recognize it correctly and prevents the scheduled task from triggering
  • Remove the extra characters, rebuild the container, and the task will run normally

Multiple machine deployment of workspace, to prevent duplicate triggering of scheduled tasks#

  • 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.