5

I've been pulling my hair out over this one for a few days.

I have a Laravel web app that I'm trying to deploy to my webserver. I started making the app a few weeks ago and started with a fresh Laravel installation of the latest stable build.

When I first tried to install Laravel via composer it told me my PHP version was out of date. I needed 7.3 or higher and had 7.2 installed. I went ahead and followed this guide on installing php 7.4.

At first, I was getting a default 503 service unavailable error in Apache that I was able to pin down to a ProxyPass error on another domain virtual host. This was displayed in the Apache error logs when I checked them.

For now, I went ahead and simply disabled that site as it hasn't been in use for some time anyway.

Upon doing so I now get a styled "500 | Server error" screen which matches the Laravel default error code screens. However, the storage/logs/laravel.log has no new errors when I go to check it. If I try to run artisan commands as php artisan migrate the log does correctly write the output of these errors to the file. So it's not a permission error where the log cannot be written at all.

As it stands I've got the following installed on my webserver.

  • Laravel 8.12
  • PHP 7.4.13 (cli)
  • Apache 2.4.29

So far what I've tried...

  • The .env file is successfully created and has correct permissions. (it does)
  • Debugging is enabled (it is)
  • As I've done with other Laravel installs on this server I made sure the file permissions are correctly set. (they are)
  • I've checked my virtual host file (attached below) and it is a copy of one of my other Laravel sites virtual hosts with the relevant information changed. My other Laravel sites hosted on this server (2 other projects) are functioning normally.
  • I made sure all of the php modules required by Laravel are installed and up to date. (they are as far as I can tell)
  • Manually set debugging to true in config/app.php and reloaded the config cache with php artisan config:cache

Domains Virtual Host File:

<VirtualHost *:80>
    ServerAdmin myemail@gmail.com
    ServerName workworkwork.fitness
    ServerAlias workworkwork.fitness
    DocumentRoot /var/www/html/workout/public
    <Directory /var/www/html/workout/public>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
    </Directory>
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =workworkwork.fitness
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

If anyone has any ideas on how to debug this error the help would be greatly appreciated. As with deploying sites or setting up new domains I've run into issues before but usually Stack Overflow or other sites have easily Google-able resolutions. However, I haven't found one that works for me on this site yet. And without Apache or Laravel error reporting it's hard to know where to even begin.

Hedayatullah Sarwary
  • 2,664
  • 3
  • 24
  • 38
Jem
  • 744
  • 2
  • 7
  • 25
  • 1
    For any 500 error there has to be a log entry, generally speaking. Try to clear out `storage/logs/laravel.log` and refresh the page then check if there's any entry in the log file. Also check if there's any other log file maybe date wise in the logs folder. If you remove the last three lines of virtual host config i.e. allow the `.htaccess` file which comes with standard laravel app to handle the pretty url stuff, does the error still persist? – Donkarnash Dec 21 '20 at 00:09
  • @Donkarnash That was a good point to remove the rewrite conditions, I'm not super used to writing virtual host so admittedly this is somewhat cobbled together from a lot of reading. Removing them does not change the behavior. Still a 500 error. I cleared the log file. Nothing new to report. If I enter a artisan command through the terminal that I know will error out, those do write to the file still. So I can't figure out where these are being lost to. – Jem Dec 21 '20 at 00:32
  • Confirm that virtual host is pointed well and working well by setting `phpinfo();exit;` at beginning of `./public/index.php` file. Also that will tell you if Apache's PHP uses PHP 7.4 – Tpojka Dec 21 '20 at 01:28
  • `php artisan config:cache`? – Ratto Dec 21 '20 at 01:48
  • Temporarily define a new '/' route in one of the other two projects running successfully on the same server as a closure and `return phpinfo()` from the closure. Then visit the '/' route and see which php version is configured for apache. – Donkarnash Dec 21 '20 at 02:28
  • If you run `php artisan` without any commands, does it log any error in the log file? Or show any error in the terminal? – Donkarnash Dec 21 '20 at 02:39

1 Answers1

2

This issue was resolved some time ago and I don't remember the exact steps (sorry I didn't remember to update this sooner) but I do have some things for people who may stumble upon this in the future to check.

What I learned that may help some others if they encounter a similar issue.

  • BIGGEST NOTE: If you have Certbot or Let's Encrypt running on your server. Check their error logs. It has it's own logs which can give insight as to how request are being handled. Typically they are in /var/log/letsencrypt/. I should have mentioned this in my initial posts. Once I did some of the other steps below to eliminate possible issues I renewed my certificates, and their redirects from HTTP to HTTPS and this solved the issue. I believe this had to do with the RewriteRule ^ in one domain was configured incorrectly with a typo. That domain also had ProxyPass enabled. I think between that typo, then the autogenerated certificates from CerBot. Something broke down somewhere. Once that was pinned down, corrected, and the certs were reissued, the problem resolved.
  • Apache handles virtual hosts alphabetically. In my case the domain encountering the issue was the lowest in alphabetical order. In the case of my logs I noticed the traffic attempting to reach this domain was being routed through another one. This led me to start taking a look at the virtual host for that domain and how it was configured. Notice too this was not indicated as an error, it acted as if it was supposed to do this based on some virtual host configuration. Not all errors are errors basically. Something in this was letting Apache think it worked correctly yet Laravel was displaying an app status error for itself as 500.
  • Disabled all virtual hosts that aren't in use or immediately necessary. In my case I had some old virtual hosts still up and running for test domains, abandoned side projects, ect. Process of elimination works great. Slowly take out things that can be causing the issue until it works and then you've got a better idea what was hampering it. Naturally you'll want to bring a lot of those back online, or it won't always be an option to take things offline. Last resort for many but still helped me.
Jem
  • 744
  • 2
  • 7
  • 25