First, check the IdP process logs. Only the most severe and exotic errors can cause the IdP to abort without writing something in this log file. If there is no error in this file, check your servlet container logs. Any error that results prevents the IdP from writing to its process log is connected to the servlet container being unable to even load the IdP classes (e.g. because the WAR file is corrupt).
First, change the logging level level for the edu.internet2.middleware.shibboleth to
DEBUG. If, after reviewing the logs, the cause of the behavior is not obvious you may need also need to change logging of org.opensaml to
DEBUG. You need not restart the IdP for these changes to take effect. The IdP checks the logging configuration file for changes every 5 minutes. Also, while the Shibboleth 2 logging system is much more efficient than system used in previous versions you should never run a production IdP on debug level during normal operations. Sensitive information may be logged and the log files will quickly grow to an unmanageable size.
First, before sending an email to the list, you should always check the common errors page. If your error is not there then send an email to the mailing list indicating which version of the IdP you are running and provide the the portion of your idp-process logs, at debug level, that contain the error. You should include approximately 50 lines prior to the error so that people attempting to help you can see what might have led up to the error. You should not email a multi-megabyte log file to the email list.