sssd - System Security Services Daemon
provides a set of daemons to manage access to remote directories and
authentication mechanisms. It provides an NSS and PAM interface toward the
system and a pluggable backend system to connect to multiple different account
sources as well as D-Bus interface. It is also the basis to provide client
auditing and policy services for projects like FreeIPA. It provides a more
robust database to store local users as well as extended user data.
SSSD supports two representations for
specifying the debug level. The simplest is to specify a decimal value from
0-9, which represents enabling that level and all lower-level debug messages.
The more comprehensive option is to specify a hexadecimal bitmask to enable or
disable specific levels (such as if you wish to suppress a level).
Please note that each SSSD service logs into its own log file. Also please note
that enabling “debug_level” in the “[sssd]”
section only enables debugging just for the sssd process itself, not for the
responder or provider processes. The “debug_level” parameter
should be added to all sections that you wish to produce debug logs from.
In addition to changing the log level in the config file using the
“debug_level” parameter, which is persistent, but requires SSSD
restart, it is also possible to change the debug level on the fly using the
Currently supported debug levels:
: Fatal failures. Anything that would prevent SSSD from
starting up or causes it to cease running.
: Critical failures. An error that doesn't kill SSSD, but
one that indicates that at least one major feature is not going to work
: Serious failures. An error announcing that a particular
request or operation has failed.
: Minor failures. These are the errors that would
percolate down to cause the operation failure of 2.
: Configuration settings.
: Function data.
: Trace messages for operation functions.
: Trace messages for internal control functions.
: Contents of function-internal variables that may be
: Extremely low-level tracing information.
To log required bitmask debug levels, simply add their numbers together as shown
in following examples:
: To log fatal failures, critical failures, serious failures and
function data use 0x0270.
: To log fatal failures, configuration settings, function data,
trace messages for internal control functions use 0x1310.
: The bitmask format of debug levels was introduced in 1.7.0.
: Add a timestamp to the debug
: Disable timestamp in the debug messages
: Add microseconds to the timestamp in
: Disable microseconds in timestamp
Send the debug output to files instead of
stderr. By default, the log files are stored in /var/log/sssd and there are
separate log files for every SSSD service and domain.
Become a daemon after starting up.
Run in the foreground, don't become a
Specify a non-default config file. The default
is /etc/sssd/sssd.conf. For reference on the config file syntax and options,
consult the sssd.conf(5) manual page.
Display help message and exit.
Print version number and exit.
Informs the SSSD to gracefully terminate all
of its child processes and then shut down the monitor.
Tells the SSSD to stop writing to its current
debug file descriptors and to close and reopen them. This is meant to
facilitate log rolling with programs like logrotate.
Tells the SSSD to simulate offline operation
for the duration of the “offline_timeout” parameter. This is
useful for testing. The signal can be sent to either the sssd process or any
sssd_be process directly.
Tells the SSSD to go online immediately. This
is useful for testing. The signal can be sent to either the sssd process or
any sssd_be process directly.
If the environment variable SSS_NSS_USE_MEMCACHE is set to "NO",
client applications will not use the fast in memory cache.
The SSSD upstream - https://pagure.io/SSSD/sssd/