This document describes the inter-process communication mechanism that is used between various SSSD components.
The SSSD consists of several processes, each of them has its own function. The SSSD processes can be one of the following:
The purpose of the monitor process is to spawn the other processes and to make sure they are restarted if they exit unexpectedly. There is only one instance of the monitor process at a given time.
The backend process communicates with the remote server (e.g. queries the remote server for a user) and updates the cache (e.g. writes the user entry). There is one backend process per domain.
The system libraries (such as the Name Service Switch module or the PAM module) communicate with the corresponding responder process. When the responder process receives a query, it checks the cache first and attempts to return the requested data from cache. If the data is not cached (or is expired), the responder sends a message to the backend requesting the cache to be updated. When the backend is done updating the cache, the responder process checks the cache again and returns the updated data. It is important to note that the responder process never returns the data directly from the server, the data is always written to the cache by the backend process and returned to the calling library in the responder process.
SSSD runs in asynchronous mode so it is able to serve multiple requests in parallel. However, this is not achieved by threads but by event driven programming. Therefore operations that cannot be executed in a non-blocking way are run in a special helper process. The helper process is spawned so it can perform an otherwise blocking operation (e.g.
kinit). Example of such process are
- Clients and client libraries
A client is an external process that talks to SSSD responders through their relevant client libraries. For example the application that wants to authenticate the user via PAM is a client that talks through
pam_sss.soclient library with the SSSD’s PAM responder.
SSSD uses three kinds of inter-process communication methods.
The D-Bus protocol is used for communication between core SSSD components – monitor, backends and responders.
- Client wire protocol
SSSD implements a custom wire protocol over well known sockets for communication between client libraries and responders.
- UNIX signals
SSSD processes also listen to various UNIX signals.
SSSD uses the D-Bus protocol for inter-process communication between its components. However, it does not use the public system bus, but rather runs a private D-Bus server.
D-Bus is not used directly but SSSD implements a wrapper around
sbus which integrates D-Bus with
talloc – the
event and memory managements libraries that are heavily used inside SSSD. The
sbus are used interchangeably in the developers
The D-Bus protocol consists of several primary components:
- D-Bus server
The server accepts connections and routes communication (messages) between two or more endpoints. Each connection to the server is associated with one or more well-known or anonymous names and can send and also receive messages from another connection.
- D-Bus message
The message is a key communication component that is transmitted between two or more connections. There are three types of messages – method call, signal and error.
The method call is a unicast message that can be replied to.
The error message is a possible reply to the method call.
The signal is a broadcast message that is sent to every one that listens to it.
- System bus
The system bus is a well-known instance of a D-Bus server. There is one system bus that can be accessed by all users.
- Session bus
The session bus is another well-known instance of a D-Bus server. There is one session bus per user session and it can be accessed only by the user.
SSSD creates several local
AF_UNIX sockets. These sockets are used for
communication between clients (e.g.
nss_sss) and SSSD responders (e.g. the
All clients employ a request/response protocol using their own TLV-encoding. Note that the clients only support synchronous I/O so sending a request to the SSSD responder is a blocking operation – it will await the response on the client side. The responder itself supports asynchronous I/O using tevent event library so it can serve multiple client’s requests in parallel.
All SSSD components listen to several standard signals. It is usually enough to send the signal to the main monitor process, which will then propagate it to other components.
Terminates a process gracefully.
In cases where an unresponsive worker process does not terminate after receiving SIGTERM, the monitor forcibly kills it with SIGKILL.
Switch SSSD to offline state. This signal is mostly useful for testing. It can be send to a single backend or to the monitor process. If it is recieved by the monitor process then all backends are moved to the offline state.
This is similar to
SIGUSR1. It will reset the offline state, making SSSD to reconnect to the remote server on next request.
This signal can be send to the monitor only. It will cause log files rotation and clearing in-memory caches. Please note that this signal is commonly used to re-read service configuration, but SSSD does not support this. To reload the configuration you must restart the service.