SSSD(8)

📦
version 2.13.1 · 21 versions
, in fedora 43, fedora 44

💖 SSSD — the manual page, but make it make sense 💖

okay bestie, gather round, because this is SSSD(8) from the SSSD Manual pages and it's literally the whole system security services daemon situation. she's the backbone. she's the moment. let's go 🫶

✨ NAME ✨

sssd — System Security Services Daemon. that's it, that's her 👑

🌸 SYNOPSIS 🌸

sssd [options]

🦋 DESCRIPTION 🦋

so SSSD is like... a whole set of daemons (plural, a squad, a friend group) whose job is managing access to remote directories and authentication mechanisms. she gives you an NSS and PAM interface toward the system, plus a pluggable backend system so you can connect to multiple different account sources, and a D-Bus interface too. multitasking icon 💅

she's also the basis for client auditing and policy services for projects like FreeIPA. and she provides a more robust database to store local users as well as extended user data. no cap.

🎀 OPTIONS 🎀

  • -d, --debug-level LEVEL — sets how chatty SSSD is. here's the thing though, there are two representations for specifying the debug level:
    • the simplest one: just give a decimal value from 0-9, which enables that level and all lower-level debug messages.
    • the more comprehensive one: a hexadecimal bitmask, so you can enable or disable specific levels (super useful if you wanna suppress a level entirely).
please note that each SSSD service logs into its own log file. and also please note that enabling “debug_level” in the “[sssd]” section only enables debugging for the sssd process itself, not for the responder or provider processes. the “debug_level” parameter should be added to all sections you wish to produce debug logs from. don't forget or you'll be sad 😭

and hey, besides changing the log level in the config file using the “debug_level” parameter (which is persistent, but requires an SSSD restart), you can also change the debug level on the fly using the sss_debuglevel(8) tool. cute.

currently supported debug levels:

  • 0, 0x0010: Fatal failures. anything that would prevent SSSD from starting up or causes it to cease running.
  • 1, 0x0020: Critical failures. an error that doesn't kill SSSD, but one that indicates at least one major feature is not going to work properly.
  • 2, 0x0040: Serious failures. an error announcing that a particular request or operation has failed.
  • 3, 0x0080: Minor failures. these are the errors that would percolate down to cause the operation failure of 2.
  • 4, 0x0100: Configuration settings.
  • 5, 0x0200: Function data.
  • 6, 0x0400: Trace messages for operation functions.
  • 7, 0x1000: Trace messages for internal control functions.
  • 8, 0x2000: Contents of function-internal variables that may be interesting.
  • 9, 0x4000: Extremely low-level tracing information.
  • 9, 0x20000: Performance and statistical data — please note that due to the way requests are processed internally, the logged execution time of a request might be longer than it actually was. (yes, that 9 shows up twice, that's not a typo on my part, that's just how it is 🙈)
  • 10, 0x10000: Even more low-level libldb tracing information. Almost never really required.

to log the required bitmask debug levels, simply add their numbers together, like in these examples:

  • Example: to log fatal failures, critical failures, serious failures and function data, use 0x0270.
  • Example: to log fatal failures, configuration settings, function data, trace messages for internal control functions, use 0x1310.
Note: the bitmask format of debug levels was introduced in 1.7.0.

Default: 0x0070 (i.e. fatal, critical and serious failures; corresponds to setting 2 in decimal notation)

  • --debug-timestamps=mode
    • 1: Add a timestamp to the debug messages
    • 0: Disable timestamp in the debug messages

Default: 1

  • --debug-microseconds=mode
    • 1: Add microseconds to the timestamp in debug messages
    • 0: Disable microseconds in timestamp

Default: 0

  • --logger=value — where SSSD will send log messages.
    • stderr: Redirect debug messages to standard error output.
    • files: Redirect debug messages to the log files. by default, the log files are stored in /var/log/sssd and there are separate log files for every SSSD service and domain.
    • journald: Redirect debug messages to systemd-journald

Default: not set (falls back to journald if available, otherwise to stderr)

  • -D, --daemon — Become a daemon after starting up. she's going off to do her own thing 🧚
  • -i, --interactive — Run in the foreground, don't become a daemon. main character energy, stays right here with you.
  • -c, --config — 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.
  • -?, --help — Display help message and exit. always valid.
  • --version — Print version number and exit.

🌈 SIGNALS 🌈

  • SIGTERM/SIGINT — informs the SSSD to gracefully terminate all of its child processes and then shut down the monitor. she's not messy, she exits cleanly ✨
  • SIGHUP — 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.
  • SIGUSR1 — tells the SSSD to simulate offline operation for the duration of the “offline_timeout” parameter. useful for testing. the signal can be sent to either the sssd process or any sssd_be process directly.
  • SIGUSR2 — tells the SSSD to go online immediately. useful for testing. the signal can be sent to either the sssd process or any sssd_be process directly.
  • SIGRTMIN+1 — tells the SSSD to reschedule the periodic tasks. the internal watchdog sends this signal to the providers when a clock shift is detected, although it can be sent to any sssd_be process directly.

💜 EXIT STATUS 💜

  • 0 — SSSD was shutdown gracefully. slay.
  • 1 — Bad configuration or command line option.
  • 2 — Memory allocation error.
  • 6 — SSSD is already running. (she's already here bestie, one of her is enough 😭)
  • Other codes — Other codes denote different errors, most probably about missing required access rights. See SSSD and system logs for details.

🍓 NOTES 🍓

if the environment variable SSS_NSS_USE_MEMCACHE is set to "NO", client applications will not use the fast in-memory cache.

if the environment variable SSS_LOCKFREE is set to "NO", requests from multiple threads of a single application will be serialized.

⭐ SEE ALSO ⭐

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)

like... that's a whole friend group, and they all ate 🔥

👑 AUTHORS 👑

The SSSD upstream — https://github.com/SSSD/sssd/

and that's the whole page bestie, you're basically an SSSD expert now, iykyk 💅

this was the SSSD manual page, dated 07/08/2026, from the SSSD project — go forth and configure responsibly 🫶✨🌈

📦 where this page comes from