Koha internal server error: finding the line that caused it

The browser shows nothing useful by design — the actual Perl error is written to that instance's error log. Tail /var/log/koha/<instance>/opac-error.log for an OPAC error or intranet-error.log for a staff one, reload the page that failed, and read the first line that appears. Everything else on this page is what to do with it.

Do not read the log from the top. Open it live, then trigger the error in the browser, so the only new lines are yours:

$ sudo tail -f /var/log/koha/library/*.log

Replace library with your instance name (sudo koha-list prints it). Reload the failing page. A typical first line names the file, the line and the reason:

[Wed Aug 12 09:14:22 2026] [error] DBIx::Class::Storage::DBI::_dbh_execute(): Unknown column  'me.new_column' in 'field list' at /usr/share/koha/lib/Koha/Objects.pm line 197

This is the single most common version of the question — everything worked, apt upgrade ran, and now the OPAC 500s while the staff interface is fine, or the reverse. Two things cause almost all of it.

Upgrading the koha-common package upgrades the code. The database is upgraded separately, and until it is, the new code queries columns that do not exist yet — which is exactly the Unknown column error above.

$ sudo koha-upgrade-schema library

Plack keeps Koha loaded between requests, so new files on disk change nothing until it restarts. Memcached can also still be handing out objects built by the old code. Restart the three of them in this order:

$ sudo systemctl restart memcached$ sudo koha-plack --restart library$ sudo systemctl restart apache2

If the site returns 502 or 503 rather than 500 after that, Plack did not come back up — see Koha returns 502 or 503 after enabling Plack, which is a different failure with a different log.

Koha runs as CGI or under Plack, and in both cases an uncaught error means the process dies before it has printed a valid response. Apache has no way to describe what happened, so it emits its own generic 500. Showing the Perl error to the visitor instead would be a security problem — the trace names file paths, module versions and often the shape of a query.

So the detail is written where only the server administrator can read it, one pair of files per instance. That per-instance split is worth knowing on a server with several libraries on it: one library's errors never appear in another's log, and reading /var/log/apache2/error.log — the file most guides send you to — usually shows nothing at all.

Logs rotate, so a fault from last week may already be in a .gz beside the live file. zgrep reads those without unpacking them.