Everyone's life is easier if you try to help yourself. If you can help yourself then you have learnt and developed, and other's have been save what is often reiteration.
| Table of Contents |
|---|
Tactics
Logging
You have logs, please use them. The Logging topic contains an overview of the SP's logging features.
...
They happen. Older Shibboleth versions had overly aggressive exception handling that traps errors but often destabilizes the software or your web server, while hiding the cause of the crash so it can't be fixed. This has been changed, but will probably result in more crashes as bugs are hit.
| Tip |
|---|
If you want to restore the older aggressive exception handling, you can add the attribute |
In general, don't bother just asking "why is this crashing?". We don't know. If we did, we'd have fixed it. What you have to do, generally, is to get a stack trace and/or provide detailed log files (with significant categories on DEBUG) to help identify the cause of the crash. This is particularly essential if the crash appears to be random, as in cases where the software will run for a while without any problems and then fail.
If a crash is reproducible, it may be enough to provide a trace of the XML or other information that leads to a crash. But when it's not, you MUST figure out how to get a stack trace out or there isn't going to be any way to research the problem.
Consortium Members can ask via their support channel.
If you don't know whether you are consortium member ask.
If you are a If you want to become a member ask
If you want to support Shibboleth by becoming a member.
When asking for help on the mailing list...
...
You should not email a multi-megabyte log file to the email list, and you should also not just post your entire configuration, metadata, etc.
Specific Guides
Requests are Looping from the SP to the IdP to SP to the IdP.....
My SP Won't Protect my content or application.
Errors with address checking/comparisons