Table of Contents:
[dspace]/log/dspace.log
(usually)[dspace]
is the location where DSpace is installed.[tomcat]/logs
(usually)[tomcat]
is the location where Tomcat is installed.In DSpace 7.x or 8.x, there are two main places where detailed error messages may be found. It is important to locate these detailed error messages in order to debug any issues you are seeing. (The generic error messages that appear in the User Interface do not provide enough information to debug the problem.)
Once you locate the detailed error, see the section on "Report the Error and Describe How You Encountered It" below. |
The User Interface is built with JavaScript (Angular.io). This means that some errors are only visible in your browser (and therefore will never appear in log files).
To find the errors in your browser, you will want to open your browser's Developer Tools and then try to reproduce the error again.
If the User Interface error is a generic 500 response, that means there's an error that occurred on your backend. Check your DSpace logs or Tomcat logs for information on the exact error. See the below section on "Finding error messages in the REST API logs". |
Some (but not necessarily all) errors will result in logged errors on the backend. Similar to DSpace 6.x and below, the error message should be in either [dspace]/log/dspace.log
OR [tomcat]/logs/
.
Usually, the culprit error will appear in the logs with a line similar to one of the following:
yyyy-mm-dd time ERROR ...
OR,yyyy-mm-dd time WARN ...
If you are not seeing the error appear in the REST API logs, and the error information is minimal in the User Interface, you can tell the REST API to always return the entire error stacktrace in any error response. This is done by temporarily adding the following to your local.cfg (on the backend):
# This tells the REST API to include a "stacktrace" param in error responses # This param will include the full Java stacktrace of the error server.error.include-stacktrace = always |
Enabling this setting requires you to reboot your servlet engine (e.g. Tomcat).
Once this setting is enabled, you can reproduce the error from the User Interface. Now, the error message in your User Interface (in your browser's Developer Tools) may show the entire Java stacktrace that resulted in the error.
WARNING: Keep in mind that you should only enable this setting TEMPORARILY. Keeping this set to "always" is a security issue in Production scenarios, as it allows anyone to view the detailed stacktrace of any error they cause. These stacktraces can sometimes leak important information about your underlying system which can help hackers to find vulnerabilities.
If none of the above helped, or you are hitting a very strange backend error, you can change the DSpace logger settings to DEBUG
which will sometimes provide you with more information about the error. To turn on debugging, visit the [dspace]/config/log4j2.xml
file and do the following:
To enable DEBUG logging in the dspace.log
file, change the loglevel.dspace
Property to DEBUG
rather than INFO
.
NOTE: You'll need to restart Tomcat after enabling DEBUG mode in the log4j2.xml
file.
WARNING: Make sure to turn off debugging once you are finished. Leaving debugging turned on will cause the log files to grow very large very quickly!
See "Report the Error and Describe How You Encountered It" section immediately after this.
Before reporting any issue, it's best to check and see if the answer is already easily available.
If neither of these resulted in a solution to your error, proceed to "Reporting the error" below.
There are a few ways you may choose to report this error. However, we ask that you only choose one, depending on which you prefer.
Email a description of the error along with the error stacktrace (which you found above) to dspace-tech@googlegroups.com
If you are not a member of this list, or want more information about DSpace lists, see Mailing Lists
Other support options detailed on the DSpace Support page
MAKE SURE to include the following information:
./dspace version
" from the command line will provide much of this information for you. The error stacktrace / message that you found in your log file or Browser DevTools
[dspace]/log/dspace.log
OR [tomcat]/logs/
.[tomcat]/webapps/<name-of-webapp>/WEB-INF/logs/
[dspace]/log/cocoon.log
alert.recipient
) as the DSpace Administrator, you should receive an email with this full error listing. If not, move into the DSpace log directory ([dspace]/log
) and view the end of the log file:tail -100 dspace.log
Alternatively, you can open up the dspace.log file in your favorite text editor and look near the bottom of the file for the error message.yyyy-mm-dd time ERROR ...
OR,yyyy-mm-dd time WARN ...
See "Report the Error and Describe How You Encountered It" section immediately above for details.
If you'd like to try and do some debugging yourself, you can change the DSpace logger settings to DEBUG
which will sometimes provide you with more information about the error. To turn on debugging, visit the [dspace]/config/log4j.properties
file and do the following:
To enable DEBUG logging in the dspace.log
file, change the log4j.rootCategory
and log4j.logger.org.dspace
settings to DEBUG
rather than INFO
.
(XMLUI Only) To enable DEBUG logging in the cocoon.log
file, change the log4j.logger.org.apache.cocoon
setting to DEBUG
rather than INFO
.
NOTE: You'll need to restart Tomcat after enabling DEBUG mode in the log4j.properties
file.
WARNING: Make sure to turn off debugging once you are finished. Leaving debugging turned on will cause the log files to grow very large very quickly!
Depending on where you got your Java runtime environment, you may have the jps
command. jps -v
can show you the options actually used to run your Servlet container, which can be useful in debugging startup issues. A plain jps
command will list process IDs of running JREs, which you can use with your favorite process monitoring tools. jps
can only show processes which your user account is allowed to inspect, so you should run it as the user which runs the container, or as a superuser.