【laravel6.x】apacheのドキュメントルートでpublic直下を指定したにも関わらず、public/index.php参照時に”現在このリクエストを処理できません”などの500エラーが表示される不具合について

ブログタイトルに検索されそうなワードを色々仕込むようにしていたら最近どんどん冗長になってきて悩んでます。

世間は3連休なので自分も何かしようと思い、自作のlaravelプログラムを配置したvps環境の負債を返すべくインフラを弄っていたらタイトルの事象に遭遇したのでブログにしておきます。手順が結構レアなので遭遇するのは自分だけの可能性はありますが、誰かが助かるかもしれませんので一応。

問題発生までの流れ

【前提】vpsにlaravelのプログラムが既存で配置。ブラウザでも動かせる。
- これはscpでコードを手動で配置して用意したプロジェクト
- git管理はしている
- httpd.confなどは既存で動いている設定を調整して使い回す
改修が面倒なので、vps内でgit cloneしてコード反映できるようにしたくなった
vps内の配置したい場所でgit cloneし、laravelプログラムを複製する
clone後に足りないファイルを、既存のプログラムからコピー
- storageディレクトリとか
- .envとか
composer updateする
- “Please provide a valid cache path"のエラーが出る時もあるがググれば解決するのと、今回の記事の本題ではないので割愛
php artisan storage:linkで画像が正しく出るようにしておく
apacheのhttpd.confを調整する
- 基本Documentroot関連、Directory “…/プロジェクトのパス/public”の部分を変えれば良い
- 例えば既存のlaravelプログラムが”/var/www/html/laravel_jisaku”で、cloneしたものが”/var/www/clone” なら
- DocumentRoot “/var/www/html/laravel_jisaku/public” を、 DocumentRoot “/var/www/clone/public” とする
- 自分の場合は4ヶ所くらいあった。
service httpd restartなどで反映
URL(IP)にアクセスするとclone後のプロジェクト画面で表示されるはずだが、エラー
- chromeなら”現在このリクエストを処理できません。”というやつ

試したこと

httpd.confの文法チェック
- httpd -t で確認できる
clone後のlaravelプログラムの動作チェック
- artisanコマンドが使えるか(php artisan --versionとかでも良い)
- DB接続チェック (tinkerを起動して DB::connection(); とか打てばOK)
プログラム直下のpublicが読まれているかチェック
- 自分でindex.htmlを作って読まれるか確認
- laravel側で用意されたindex.phpにechoなどを書いて画面に出るか確認など
各種キャッシュクリア
- artisanでのクリア関連のコマンドを叩く。

上記全て試しましたが画面の表示は変わらず。

public/index.phpがそもそも読まれているか確認したかったので、開いて適当にphpを書いて確認。すると自分の場合は下記の$responseの部分で止まっているような挙動が見られました。ちなみに画面のエラーによるlaravel.logへの書き込みはありませんでした。

# .../自分のlaravelプロジェクト/public/index.php

## どこまで動いているか確認したかったので適当に書き入れた
## echo 'test'まで書いた場合は500エラーとはならずにtestという文字が画面に出るようになったが、それ以降のプログラムは動作していないような挙動に見えた。

....
echo 'test';
$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);
echo 'response ato no echo';

解決方法

# .../自分のlaravelプロジェクト/storage 及び直下のプログラムの権限を調整した
sudo chmod 777 -Rf storage

自分で弄ったところが怪しいよな〜と思ってhttpd.confと睨めっこしていたのですが、思えばstorageディレクトリと.env周辺も別の場所から持ってきたものです。そっちも怪しいと思い色々試したところ、権限を調整することで解消できました。

storageディレクトリはよくpermission deniedのエラーの原因となるのでstorage自体の権限は変更していたのですが、storage直下に存在するディレクトリへの考慮が足りていなかったことが原因だったようです（エラーメッセージが確認できなかったため確実ではないのですが、恐らく、多分、きっと）。

storage/framework の中のcache, sessions, views あたりの権限も調整してやる必要があったようですね。

これで画面にclone後のプロジェクトが表示されるようになりました。今後改修もリモートのmainブランチをpullするだけで良くなったので快適になりそうです。