SSSD Is Already Running: Fix sssd Failing to Start on RHEL, AlmaLinux and Rocky Linux

Updated: 8 October 2026 · Applies to: AlmaLinux 10.2 (SSSD 2.12.0) and AlmaLinux 9.8 (SSSD 2.9.8), the same SSSD code as RHEL and Rocky Linux 9 and 10; notes for RHEL and CentOS 7 (SSSD 1.16)

On current systems, "SSSD is already running" means SSSD found its PID file and the process number in it is still alive. Either a second copy of SSSD really is running (usually one started by hand with sssd -D), or the PID file was left behind by a crash and its number now belongs to another process. Find out which, stop the stray copy or delete the stale PID file, and start SSSD again with systemctl. The PID file is /run/sssd.pid on EL9 and /run/sssd/sssd.pid on EL10. On EL7 (SSSD 1.16, default /var/run/sssd.pid) a leftover file is enough to block the start, see below.

What the error looks like

On AlmaLinux 9, journalctl -u sssd -o cat shows:

Starting System Security Services Daemon...
SSSD is already running
sssd.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
sssd.service: Failed with result 'exit-code'.
Failed to start System Security Services Daemon.

On AlmaLinux 10 the journal only shows the exit code; the message itself is in /var/log/sssd/sssd.log:

sssd.service: Main process exited, code=exited, status=6/NOTCONFIGURED
sssd.service: Failed with result 'exit-code'.
Failed to start sssd.service - System Security Services Daemon.

[sssd] [main] (0x0010): SSSD is already running: pidfile exists at '/run/sssd/sssd.pid'

A related variant: SSSD starts, then stops a second later with Deactivated successfully, and sssd.log contains Error creating pidfile: /run/sssd/sssd.pid! (17 [File exists]). It has the same cause and the same fix.

Fix it (as root)

1. Stop the service so systemd is not retrying in the background:

   systemctl stop sssd

2. Check whether any SSSD process is still running:

   pgrep -a sssd

   If this prints nothing, no SSSD is running and the PID file is stale: go to step 4.
3. If pgrep lists processes, a copy was started outside systemd. In our AlmaLinux 9 test it looked like this:

   165 /usr/sbin/sssd -D
   166 /usr/libexec/sssd/sssd_be --domain local --uid 0 --gid 0 --logger=journald
   167 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=journald
   168 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=journald

   Stop it with kill 165 (the PID of the main sssd process, which is also the number in the PID file), wait a few seconds and run pgrep -a sssd again until it prints nothing. While that copy runs, systemctl start sssd can hang in "activating (start)".
4. Look at the PID file and see which process owns that number:

   cat /run/sssd/sssd.pid        # EL10 (EL9: /run/sssd.pid)
   ps -o pid,user,comm -p "$(cat /run/sssd/sssd.pid)"

   In our AlmaLinux 10 test the stale file pointed at a number that now belonged to another program:

   1
       PID USER     COMMAND
         1 root     systemd

   That is not SSSD, so the file is stale. Delete it:

   rm -f /run/sssd/sssd.pid

5. Start SSSD and confirm it stays up:

   systemctl start sssd
   systemctl status sssd --no-pager
   pgrep -a sssd

   On AlmaLinux 10 the result was:

   586 /usr/sbin/sssd -i --logger=files
   587 /usr/libexec/sssd/sssd_be --domain local --logger=files
   588 /usr/libexec/sssd/sssd_nss --logger=files
   589 /usr/libexec/sssd/sssd_pam --logger=files

Never delete the PID file of an SSSD that is still running: you would end up with two copies fighting over the same cache.

Why it happens, and how the versions differ

• EL9 and EL10 (SSSD 2.9 and later): SSSD checks whether the PID in the file is alive. If it is not, SSSD deletes the file itself and starts normally; we confirmed this by writing a dead PID into the file. So on current systems the error almost always means a real second copy, or a stale file whose number was reused by another process.
• EL9: the unit file has PIDFile=/run/sssd.pid, so systemd removes the file after a failed start. In our test a second systemctl start sssd then worked. EL10's unit has no PIDFile=, so the stale file stays until you delete it.
• EL10: SSSD runs as the unprivileged sssd user (User=sssd in the unit). Do not run /usr/sbin/sssd by hand as root to "test" it: in our test that left /var/lib/sss/db/config.ldb owned by root, and the InfoPipe responder then logged Unable to open tdb '/var/lib/sss/db/config.ldb': Permission denied. systemctl restart sssd fixed the ownership, because the unit runs chown on those files before it starts.
• RHEL and CentOS 7 (SSSD 1.16): according to the SSSD 1.16 source code, SSSD only checks that /var/run/sssd.pid exists and does not test whether the process is alive. After a crash or kill -9, every start fails until you delete the file, which is what the original version of this article described. CentOS 7 is end of life; plan a move to AlmaLinux or Rocky Linux 9 or 10.

If SSSD still does not start

• Validate the configuration. A typo gives clear output:

  sssctl config-check
  Issues identified by validators: 2
  [rule/allowed_domain_options]: Attribute 'id_provder' is not allowed in section 'domain/local'. Check for typos.
  [rule/sssd_checks]: Attribute 'id_provider' is missing in section 'domain/local'.

• Check the permissions of /etc/sssd/sssd.conf. On EL9 a file with mode 0644 fails with File ownership and permissions check failed and exit status 4/NOPERMISSION; sssctl config-check then says Expected root:root and 0600. Fix it with chown root:root /etc/sssd/sssd.conf && chmod 600 /etc/sssd/sssd.conf. On EL10 the unit sets the group to sssd and adds group read access by itself.
• The unit allows 5 starts within 50 seconds (StartLimitBurst=5, StartLimitIntervalSec=50s). If you hit that limit while testing, run systemctl reset-failed sssd before the next start.
• Once SSSD runs, sssctl domain-list and sssctl domain-status DOMAIN show whether the domain is online.
• For more detail, add debug_level = 6 to the [sssd] or [domain/...] section, restart SSSD and read the matching file in /var/log/sssd/. Do not delete the cache in /var/lib/sss/db/ on a system that is offline: it also holds cached logins.

Related guides: check the status of a service with systemctl, journalctl command examples and join Linux to Active Directory with realmd and SSSD. If you would rather have our engineers look after your servers, see Linux server management.

Official documentation: SSSD troubleshooting basics