Log Handling

I

indieben

Verified User
Joined
Mar 28, 2024
Messages
30
Hi, I have php error display on within DA but I have a 500 error where I do not get any verbose screen output.

Further, the logs section of the domain that I am attempting to use isn't capturing anything either.

I am at a bit of a loss as to how get anything more comprehensive. Google as standard suggests log files for Nginx but I use Apache2.

Thanks.
 
Are you checking the error log for the domain? The 500 error will be there.
 
Hi Floyd,

From within the GUI in site summary/statistics/logs, yes, that's where I started and yes I had selected the relevant error log to the domain. Unfortunately, no, there was no error triggered for the install or even anything that could remotely be construed as such.

Per https://www.interserver.net/tips/kb/important-log-file-locations-in-directadmin/

I checked:

# /var/log/httpd/error_log -> Access denied from within virtual terminal for httpd

# /var/log/httpd/access_log Access denied from within virtual terminal for httpd

# /var/log/httpd/suexec_log Access denied from within virtual terminal for httpd

# /var/log/httpd/fpexec_log Access denied from within virtual terminal for httpd

# /var/log/httpd/domains/domain.com.error.log Access denied from within virtual terminal for httpd

# /var/log/httpd/domains/domain.com.log Access denied from within virtual terminal for httpd

# /var/log/messages (generic errors) -> Doesn't exist

I did it this way as I would expect clients to be able to check their errors too. It's no good just for an admin too and it will frustrate clients not being able to get comprehensive and reliable error reporting.

Many thanks.
 
Running PHP 8.2, Ioncube present, Ubuntu environment. 500 error gives no clues, Error handling turned on, would expect verbosity on the screen, would expect errors area of the DA web interface for the domain my.domain.com to be telling me something.

For the sake of competeness, much earlier, there is one solitary complaint within the errors area of the DA web interface relating to SSL - but I believe this will have resolved itself and it was from when I first created the domain. Let's Encrypt generally fixes such issues within not very long - hours at most. I have tried again after several hours and the error has not regenerated anyway.

Per @RichardG 's reply on post https://forum.directadmin.com/threads/where-is-the-php-error-log-location.61012/, although I may have misunderstood it, I added to the .htaccess within the directory that I am trying to run the PHP Script (my.domain.com/public_html/blesta) and in attempting to run blesta/install.php and just hitting /blesta:

Aren't php errors also logged in your domains error logfile? You should be able to visit that one via your DA panel as user under Site Summary / Statistics / Logs.

Otherwise, in apache, you could add something like this temporarily in the .htaccess file:
Code:
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_value error_log /home/user/domains/domain.com/public_html/PHPERROR.log
Click to expand...

Whilst I appreciate that this is an old post, I received some animosity in a separate post suggesting that I had not checked the forums and defending old posts as still relevant on the basis that DA had not changed that much - so, if there is to be any criticism of doing that, I can't win.

I appreciate that Richard's comment says "in Apache". I interpreted this as "when running Apache" as it's the first time that I have heard of creating a .htaccess file for a non public directory. In any event, going down this route is hardly ideal to attempt to compensate for something that a stock DA install should do out of the packet and where DA's easy installer is clearly intended to ensure that, on a clean VPS, it runs as expected. I am running Ubuntu but I rather doubt this changes the price of fish otherwise I would have expected errors in the install where DA could not do what it intended....

Unfortunately, it didn't work anyway.

I am totally stumped, DA clearly has a place within the Web interface for errors to be logged and yet it doesn't log the errors. I am trying to run a PHP Script, it is generating a 500 error, without an error log that works, DirectAdmin isn't fit for purpose and it's like looking for a needle within a haystack, particularly with a lack of easy checking of modules. I share Richard's view expressed in the further commentary for another post reply in the above weblink for his reply:

That's the same I pointed out in my first reply "Site Summary / Statistics / Logs".
Those are the webserver domain error logs. They do not always show all php errors as I discovered. That's why I wrote the additional .htaccess option.
Click to expand...

I'll do a PHPinfo file and see if that shows any modules not available. I'll also try an install in a subdirectory of public_html. I can confirm that ioncube is present as it was requesting an update as part of DA yesterday. I can confirm that a variety of other PHP based scripts, such as WordPress and Joomla work fine so PHP is running. BTW, i'm running PHP 8.2 on the domain.

I'll raise a ticket as a backup but i'm highly unimpressed. Not your fault Floyd, I appreciate your help and if you have any further comments, please let me know. I shall post a follow-up too.

Many thanks.
 
Last edited:
indieben said:
as it's the first time that I have heard of creating a .htaccess file for a non public directory.
Click to expand...
I never wrote that it was used in a non public directory. I didn't say where to specifically put it either, because normally it's generally known to put in the public_html directory. But it can also be used in a subdirectory of a public_html.

A bit higher you write:
indieben said:
# /var/log/httpd/error_log -> Access denied from within virtual terminal for httpd
Click to expand...
Why do you get a virtual terminal error? Are you trying to reach this via KDE GUI or how did you try to reach this?
As all those logs give you the same error, but they can only be reached as root via SSH.

This is the location for your domain error log:
/var/log/httpd/domains/domain.com.error.log
But this one and the normal log are reachable via the Directadmin interface via the "Site Summary / Statistics / Logs". However that was an older post and that is in the Enhanced Skin.

In Evo skin it's under the same, but a bit harder to find maybe. It's under "System Info and Files".
And under that you see the Site summary and so on.

A direct link to the error log would nowadays in Evo skin be:
https://domain.com:2222/evo/user/stats/log/domain.com.nl/error
You can just replace the appropriate domain.com example with your own.

Normally you would see errors there or else in the normal log which would be here:
https://domain.com:2222/evo/user/stats/log/domain.com.nl/usage

Mostly information about error 500's are present in either or even both files.

But indeed, in some rare cases I needed that .htaccess adjustment. But 500's are not always caused by PHP. It can also be a permission issue for example.
 
Good Morning Richard, thanks for chipping in!

Further update, so Blesta will not install on my.domain.com but it will install on domain.com/blesta (a subdirectory of public_html). This is the problem that caused me to raise this. To reitterate, my.domain.com is created as it's own domain as opposed to a subdirectory.

Totally lost as to what the issue is. Both have the same PHP versions.

Thanks.
 
indieben said:
my.domain.com is created as it's own domain as opposed to a subdirectory.
Click to expand...
That is not required anymore.

You can also remove this domain and add it as a subdomain.
Nowadays when adding as a subdomain, it get's his own public_html and you also have the option to choose.

So if you add it as a subdomain, then you would get a directory like:
/home/user/domains/my.domain.com/public_html/
so same as you make it as a seperate domain, but this might work.

If this also does not work, then Blesta does not work from subdomains. Which is odd because some domains have more dots.
In that case you should act as @floyd wrote, because then it's a Blesta issue which they need to fix.
 
Thanks - but Blesta has previously worked on subdomains when I last tried it. What is to stop it being a DA issue or my error potentially? I can't think of anything i've done wrong, i've posted all relevant information and an error on my part has not been picked up so far but I'm open to the idea...
 
indieben said:
What is to stop it being a DA issue or my error potentially?
Click to expand...
That fact that we can't blaim DA at the moment since we don't get to see any error messages at the moment.
If you think it's DA, maybe it might, but then provide us with the log outputs we asked for and instructed how to get them in post #5.

Also, have you tried creating a subdomain like it's done nowadays as instructed in post #8?

Because we don't have had any answer on either of them, and since DA is working normally there should be no reason for Blesta not to work.
If it is that error 500 everytime, then use the suggestion in post #8. Still the error 500? Then provide us the logfiles so we can see what is causing it, as at this moment we're blind without logs.
And then if you do everything correct, we have to assume it's a Blesta issue as other applications don't have a problem.
Or we need logs or logparts to see what's going on.
 
You must log in or register to reply here.
Back
Top