質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.44%
CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

cron

cronは、Unix系OS上でデーモンプロセスとして動作する、スクリプトの自動実行が可能なジョブスケジューラです。

Laravel 5

Laravel 5は、PHPフレームワークLaravelの最新バージョンで、2014年11月に発表予定です。ディレクトリ構造がが現行版より大幅に変更されるほか、メソッドインジェクションやFormRequestの利用が可能になります。

Q&A

解決済

1回答

9541閲覧

Laravelのスケジュールに設定したCommandが実行されない

pip

総合スコア19

CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

cron

cronは、Unix系OS上でデーモンプロセスとして動作する、スクリプトの自動実行が可能なジョブスケジューラです。

Laravel 5

Laravel 5は、PHPフレームワークLaravelの最新バージョンで、2014年11月に発表予定です。ディレクトリ構造がが現行版より大幅に変更されるほか、メソッドインジェクションやFormRequestの利用が可能になります。

0グッド

1クリップ

投稿2018/06/12 08:26

編集2018/06/14 09:39

状況

laravelでアプリケーションを作っており、cronで定期的に行うタスクを追加しています。
タスクは下記のように指定していますが、Laravelで設定しているcommandが実行されません。

cron.dで設定しているタスク

rootのcron.dに下記を設定しています。

cron.d

1* * * * * root /opt/lampp/bin/php /home/project/artisan schedule:run >> /dumplog.txt

Laravel側のスケジュール

Console/Kernel.php

php

1<?php 2 3namespace App\Console; 4 5use Illuminate\Console\Scheduling\Schedule; 6use Illuminate\Foundation\Console\Kernel as ConsoleKernel; 7 8class Kernel extends ConsoleKernel 9{ 10 /** 11 * The Artisan commands provided by your application. 12 * 13 * @var array 14 */ 15 protected $commands = [ 16 \App\Console\Commands\Test::class, 17 ]; 18 19 /** 20 * Define the application's command schedule. 21 * 22 * @param \Illuminate\Console\Scheduling\Schedule $schedule 23 * @return void 24 */ 25 protected function schedule(Schedule $schedule) 26 { 27 28 $schedule->command('command:test') 29 ->cron('* * * * * *') 30 ->before(function(){ 31 $monolog = \Log::getMonolog(); 32 $monolog->info('start scedule'); 33 }) 34 ->timezone('Asia/Tokyo') 35 ->after(function(){ 36 $monolog = \Log::getMonolog(); 37 $monolog->info('end scedule'); 38 }); 39 } 40 41 /** 42 * Register the commands for the application. 43 * 44 * @return void 45 */ 46 protected function commands() 47 { 48 $this->load(__DIR__.'/Commands'); 49 50 require base_path('routes/console.php'); 51 } 52} 53

command:testは下記を実行します。
Console/Commands/Test.php

<?php namespace App\Console\Commands; use Illuminate\Console\Command; class Test extends Command { /** * The name and signature of the console command. * * @var string */ protected $signature = 'command:test'; /** * The console command description. * * @var string */ protected $description = 'Command Test'; /** * Create a new command instance. * * @return void */ public function __construct() { parent::__construct(); } /** * Execute the console command. * * @return mixed */ public function handle() { $monolog = \Log::getMonolog(); $monolog->info('handle start'); } }

想定される結果

下記のように、storage/logs/laravel.logに追加される。

[2018-06-14 14:30:02] staging.INFO: start scedule [2018-06-14 14:30:02] staging.INFO: handle start [2018-06-14 14:30:02] staging.INFO: end scedule [2018-06-14 14:31:01] staging.INFO: start scedule [2018-06-14 14:31:01] staging.INFO: handle start [2018-06-14 14:31:01] staging.INFO: end scedule

現象

毎分指定しているスケジュールなのですが、指定したcommandが実行できていません。

laravelログ

[2018-06-14 14:30:02] staging.INFO: start scedule [2018-06-14 14:30:02] staging.INFO: end scedule [2018-06-14 14:31:01] staging.INFO: start scedule [2018-06-14 14:31:01] staging.INFO: end scedule

cronログ

取得時間に際がありますが、cronで、スケジュールの実行自体はされています。

Jun 14 12:59:01 ik1-325-22848 CROND[6628]: (root) CMD (/opt/lampp/bin/php /home/project/artisan schedule:run >> /dumplog.txt) Jun 14 13:00:01 ik1-325-22848 CROND[6649]: (root) CMD (/opt/lampp/bin/php /home/project/artisan schedule:run >> /dumplog.txt)

cronで実行したタスクのログ(dumplog.txt)

毎分出力する設定にしていますので、指定したスケジュールで、実行自体はしているのはわかります。

Running scheduled command: '/opt/lampp/bin/php-7.1.14' 'artisan' command:test > '/dev/null' 2>&1 Running scheduled command: '/opt/lampp/bin/php-7.1.14' 'artisan' command:test > '/dev/null' 2>&1 Running scheduled command: '/opt/lampp/bin/php-7.1.14' 'artisan' command:test > '/dev/null' 2>&1

わかっている事

laravelのバージョン

Laravel Framework 5.5.40

環境

OSは、「CentOS release 6.9」です。
phpはxamppに入っているものを使用しています。

cronの状況

cronのlogを見ると、毎分タスクが実行されているようなので、crontabが止まっている訳ではなさそうです。

Laravelのプロジェクトのディレクトリ

projectユーザーのホームディレクトリ配下に展開しています。
projectユーザーのホームディレクトリは、/home/project/です。

試した事

commandで意図的にエラーを起こす

もしかして、Commandにエラーがあってもエラーをログに吐かないのかと思い、意図的に構文エラーをして見ました。

public function handle() { $monolog = \Log::getMonolog() $monolog->info('handle start'); }

その結果、下記のエラーが吐き出されるので、Command自体は実行されています。

sh

1staging.ERROR: Parse error: syntax error, unexpected '$monolog' (T_VARIABLE) {"exception":"[object] (Symfony\Component\Debug\Exception\FatalThrowableError(code: 0): Parse error: syntax error, unexpected '$monolog' (T_VARIABLE) at /home/project/app/Console/Commands/Test.php:41)

storageに書き出す部分のみの問題な気がします。
何故、scheduleのbeforeとafterは良くて、Commandが書き出せないのかわかりませんが…

storageディレクトリ以下のパーミッションを777にする。

laravel.logのパーミッションが元々「-rw-r--r--」で、projectユーザー(作業ユーザー)しかさわれない状態だったので、laravel.logのパーミッションを777にしてみましたが、logsに書き込まれませんでした。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

mix-peach

2018/06/13 03:42

うーん。。何か違う部分が原因のような気がしますが。。。 crontabを設定したアカウントと、commandの実行を確認した時のアカウントは、同じですか? あと、 command:test の中でログとか既存ファイルへの出力とかをしていますか?
pip

2018/06/13 06:07

ありがとうございます。状況を整理して追記させていただきます。
mix-peach

2018/06/14 01:28

artisanのパスが書き換わっている、と書いてありますが、私の手元のlaravel環境でも同じようになりますし、その上でschedule:runの中のコマンドは正常に動きます。ログ出力、ディレクトリやファイル作成、既存ディレクトリや既存ファイルへの書き込みなどを行っているのであれば、パーミッションエラーで落ちている可能性を疑うべきかと思われます。ちなみに、これで落ちている場合、エラーログもパーミッションエラーで書き込めないので、エラーが発生しているようにも見えないという難点が・・・。
pip

2018/06/14 03:20

なるほどですね。外部ファイルへの書き込みをしていますので、パーミッションの可能性があります。一度、外部出力を削ってlaravelログを出力するだけ確認して見たのですが、出力されないようなのでそもそも、スケジュールの設定方法にも誤りがあるかもしれません。
pip

2018/06/14 03:21

質問の内容を変えて見ます。
mix-peach

2018/06/14 08:41

色々試されてるみたいですね・・。Console/Commands/Test.php は、artisanコマンドから作成されましたか?あと、laravelのバージョンはいくつでしょう?5.?←ここが知りたいです。
pip

2018/06/14 09:30

お忙しいところ度々ありがとうございます。「php artisan command:test」で実行できることは確認しました。rootアカウントでも実行できます。ララベルのバージョンは5.5.40です。
pip

2018/06/14 09:33

元々、他のサーバーで稼働していたシステムのソースを流用して作ったシステムで、そのシステムではscheduleの処理が出来ています。流用して別サーバーで運用したところこの現象が起こり始めたので、サーバーの差異も見ているのですがこれといった違いが見当たらず、引き続き調査している次第です。
mix-peach

2018/06/18 07:09 編集

あ。コマンドを直に実行すれば動くんでしたね! となると、コマンド実行者の違いが原因かもしれません。schedule:run (before、after含む)は、crontabを設定したアカウント(ログから見るに、root)で動くと思うのですが、そこから呼ばれるcommand:testを動かしているのは、ファイル(プロジェクト?)の所有者かapacheかだと思うので、そこらへんの差が「書き出せるか出せないか」に影響しているのかも?(そうすると、やはりパーミッションの話ですかね? でもログファイルの権限「777」で確認されてるんですよね・・不思議ですね・・) ちなみに、apacheのログとかにも、エラーは出てないですか?
pip

2018/07/18 06:46

ご回答ありがとうございます。時間をおいてしまい失礼しました。結局根本的な解決には至らず…サーバーを変えたところ解決できたので案件自体は終わりました。取り急ぎご共有まで
guest

回答1

0

自己解決

根本的な解決はしませんでしたが、
サーバーを変えて一から作り直したところ解決しました。

投稿2018/07/18 06:47

pip

総合スコア19

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.44%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問