12.5. SSSD log files and logging levels
Each SSSD service logs into its own log file in the /var/log/sssd/ directory. For an IdM server in the example.com IdM domain, its log files might look like this:
[root@server ~]# ls -l /var/log/sssd/ total 620 -rw-------. 1 root root 0 Mar 29 09:21 krb5_child.log -rw-------. 1 root root 14324 Mar 29 09:50 ldap_child.log -rw-------. 1 root root 212870 Mar 29 09:50 sssd_example.com.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_ifp.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_implicit_files.log -rw-------. 1 root root 0 Mar 29 09:21 sssd.log -rw-------. 1 root root 219873 Mar 29 10:03 sssd_nss.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_pac.log -rw-------. 1 root root 13105 Mar 29 09:21 sssd_pam.log -rw-------. 1 root root 9390 Mar 29 09:21 sssd_ssh.log -rw-------. 1 root root 0 Mar 29 09:21 sssd_sudo.log
12.5.1. SSSD log file purposes
krb5_child.log- Log file for the short-lived helper process involved in Kerberos authentication.
ldap_child.log- Log file for the short-lived helper process involved in getting a Kerberos ticket for the communication with the LDAP server.
sssd_<example.com>.logFor each domain section in the
sssd.conffile, the SSSD service logs information about communication with the LDAP server to a separate log file. For example, in an environment with an IdM domain namedexample.com, the SSSD service logs its information in a file namedsssd_example.com.log. If a host is directly integrated with an AD domain namedad.example.com, information is logged to a file namedsssd_ad.example.com.log.NoteIf you have an IdM environment and a cross-forest trust with an AD domain, information about the AD domain is still logged to the log file for the IdM domain.
Similarly, if a host is directly integrated to an AD domain, information about any child domains is written in the log file for the primary domain.
selinux_child.log- Log file for the short-lived helper process that retrieves and sets SELinux information.
sssd.log- Log file for SSSD monitoring and communicating with its responder and backend processes.
sssd_ifp.log- Log file for the InfoPipe responder, which provides a public D-Bus interface accessible over the system bus.
sssd_nss.log- Log file for the Name Services Switch (NSS) responder that retrieves user and group information.
sssd_pac.log- Log file for the Microsoft Privilege Attribute Certificate (PAC) responder, which collects the PAC from AD Kerberos tickets and derives information about AD users from the PAC, which avoids requesting it directly from AD.
sssd_pam.log- Log file for the Pluggable Authentication Module (PAM) responder.
sssd_ssh.log- Log file for the SSH responder process.
12.5.2. SSSD logging levels
Setting a debug level also enables all debug levels below it. For example, setting the debug level at 6 also enables debug levels 0 through 5.
| Level | Description |
|---|---|
| 0 | Fatal failures. Errors that prevent the SSSD service from starting up or cause it to terminate. |
| 1 | Critical failures. Errors that do not terminate the SSSD service, but at least one major feature is not working properly. |
| 2 | Serious failures. Errors announcing that a particular request or operation has failed. This is the default debug log level. |
| 3 | Minor failures. Errors that cause the operation failures captured at level 2. |
| 4 | Configuration settings. |
| 5 | Function data. |
| 6 | Trace messages for operation functions. |
| 7 | Trace messages for internal control functions. |
| 8 | Contents of function-internal variables. |
| 9 | Extremely low-level tracing information. |
