| Table of Contents |
|---|
Logging
Diagnostics
The two "halves" of the SP software write to separate diagnostic log files by default, as configured by the shibd.logger and native.logger logging setup files. Some native.log messages will also be routed to the web server's own log or the Windows error log.
| Tip |
|---|
It's common, particularly on non-Windows platforms, for the web server "half" to produce no dedicated logging because of Apache's restricted permissions. If you don't see that log, you'll have to adjust file permissions so that the Apache user account (typically "www", "apache", or "nobody") has the ability to create and write to files in the necessary directory. |
Most of the interesting and relevant information will usually be found in the shibd.log, particularly SAML-related problems, Metadata issues, and most security issues.
It's somewhat rare to actually need the native.log (which is one reason the permission issue noted above has never been seriously addressed). Under routine use, very little ends up in that log (or at least not only there), but one common problem that may depend on using it is the pass-through issue.
The typical logging levels can be described thusly:
DEBUG | Low-level tracing, usually unneeded except when isolating crashes or developing. |
INFO | Routine indications of activity, usually the default logging level. |
WARN | Indicates something that's noteworthy, but not an actual error. |
ERROR | Something's wrong. Users are likely to be affected any time one appears. |
CRIT | Something's so wrong that attention is required or widespread problems will result. |
FATAL | Usually indicates a failure to start or continue with operations. |
In most cases, it's unnecessary to raise the logging level to diagnose routine problems. Under normal operation, logging at INFO should be relatively minimal and is suitable for production use. If you see WARN messages, you should at least know why. If you see ERROR/CRIT/FATAL messages, you should be doing something about them.
Transaction/Audit
A third log is configured from within the shibd.logger setup file, and typically available in transaction.log. Each session that's created or removed is logged here along with a variety of general information, including the set of attributes obtained (but not their values). Apart from auditing or tracking down users, the main value of this information is to identify whether the SP received particular attributes or not. If you don't see something here, and there are no ERROR or WARN messages in shibd.log regarding query failures or filtering, then the attribute in question simply wasn't given to the SP.
...
The NativeSPLogging topic contains an overview of the SP's logging features.
You have logs, please use them. It is not reasonable behavior to ask support questions unless you've looked at your logs first. Often this will require both sets of logs (SP and IdP), but the SP log is usually sufficient to at least identify who's at fault.
...