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.[tomcat]/webapps/<name-of-webapp>/WEB-INF/logs/
[dspace]/log/cocoon.log
[dspace]/log/dspace.log
OR [tomcat]/logs/
. For the XMLUI, you may also want to check the Cocoon logs (see above for path) to see if any extra information can be found there.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 ...
Use the DSpace Community Resource Search engine to simultaneously search the DSpace Wiki, Issue Tracker and mailing lists (via Google).Search StackOverflow (especially the "dspace" tag) to see if this issue has been reported and solved there (as we now encourage technical questions to be asked on StackOverflow).
Finally, check the DSpace Technical FAQ for any possible information. Some commonly reported problems have answers there.
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.
In DSpace 7, 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, as the error which displays in a User Interface error popup is usually a generic message.
Once you locate the detailed error, see the section on "Found an error message! Now what?" below. |
In DSpace 7, the User Interface is built on 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!
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 stack listing 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 stack that you found in your log file