Error Log
In this page:
Where It Lives
The default error log is /var/log/apache2/error.log on Ubuntu/Debian and /var/log/httpd/error_log on RHEL-family systems. As with the access log, individual VirtualHosts can (and should, for anything beyond a single-site server) define their own with ErrorLog.
LogLevel
LogLevel controls how much detail gets written, from least to most verbose: emerg, alert, crit, error, warn, notice, info, debug. The default warn is a reasonable baseline for production; debug is far noisier and mainly useful while actively troubleshooting a specific problem, then turned back down afterward.
What You'll Actually See There
Startup problems (a config syntax error, a module that failed to load, a port already in use), permission errors (Apache's user can't read a file it's been asked to serve), PHP fatal errors and stack traces (if display_errors is off, as it should be in production, this is the *only* place they're visible), and mod_rewrite's own rewrite-log-equivalent debug output when LogLevel includes rewrite:trace all end up here.
tail -f the error log and reload the page -- the real underlying error is almost always sitting right there.Using the Error Log to Debug a Config Change
If systemctl restart apache2 fails, systemctl status apache2 often shows only a truncated summary -- the full detail (which directive, which file, which line) is almost always in the error log's most recent lines, which is why checking it is usually the very next step after a failed restart.
Example: Per-site error log and LogLevel
<VirtualHost *:80>
ServerName example.com
ErrorLog /var/log/apache2/example.com-error.log
LogLevel warn
</VirtualHost>
{# Flagged by hand after confirming a runner can't handle this example
(a shell command / go.mod file stored as a TopicExample, a language
feature the configured runner version doesn't support, or output
that blows a runner's sandbox limit) -- see TopicExample.norun.
Never render the run button for these, regardless of language,
since it would just fail at execute_code (or worse, hang the
Judge0 queue on a submission that can never finish cleanly). #}
- Only checking
systemctl statusafter a failed restart and stopping there, missing the more detailed explanation waiting in the error log. - Running production with
LogLevel debugleft on indefinitely, generating far more noise than needed and making the log harder to scan for real problems. - Not realizing PHP/application errors with
display_errorsoff (correct for production) still land in the error log -- they're just invisible in the browser, not gone entirely.
Chapter Quiz — Complete all 4 topics to unlock
0/4 topics done
Complete these topics first: