SSSD Devel page -------------- This wiki page contains a collection of tips that might be useful for SSSD developers and contributors. If you use a trick that is not mentioned here, tell us on the [https://fedorahosted.org/mailman/listinfo/sssd-devel SSSD development list] or the [irc://irc.freenode.net/sssd IRC] == When I debug an SSSD process in a debugger, it always gets killed with {{{SIGTERM}}} == The main SSSD process (the monitor) sends "heartbeat" checks called pings to the other SSSD services, both responders and providers. If the service does not respond in a specified time interval, the monitor sends the {{{SIGTERM}}} signal to the service in an attempt to terminate a non responding instance and start a new one. However, in the case a service is being traced in a debugger, it is quite common to examine the process for long enough that the monitor would consider the service hung and send SIGTERM. The SSSD has an option simply called {{{timeout}}} that specifies the interval between the pings the monitor sends to the services. Currently the monitor sends three pings before sending the terminating signals, each ping is sent after 10 seconds by default. To change the monitor settings to send pings after one hour: {{{ timeout = 3600 }}} == Using valgrind to identify memory access problems == [http://valgrind.org valgrind] is an immensely useful tool that is able to check a wide range of memory access problems - from memory leaks to use-after-free bugs. When debugging the main SSSD program, one can just run the program as a positional valgrind parameter: {{{ valgrind /usr/sbin/sssd }}} The situation is somewhat complex when the developer needs to debug one of the services that the SSSD monitor spawns. The best solution is to use the special (undocumented) parameter called {{{command}}}. By default, the "command" defaults to {{{${libexec}/sssd_${service}}}} which expands to absolute path pointing to {{{/usr/libexec/sssd/sssd_${service}}}} by default. The general format is {{{valgrind }}}. For example to debug the sss_nss process, you need to specify the following in the {{{[nss]}}} section of the sssd.conf file: {{{ command = valgrind --leak-check=full /usr/libexec/sssd/sssd_nss }}} Some of the SSSD processes, notable the sssd_be processes that represent the {{{[domain/]}}} sections of {{{sssd.conf}}}, require command line parameters in order to function correctly. The easiest way to check how exactly the SSSD spawns the worker processes is to simply check with the {{{ps(1)}}} utility: {{{ ps -axu | grep sss }}} The following example illustrates using valgrind to debug an SSSD domain called "default", which is the name authconfig uses: {{{ command = valgrind --leak-check=full /usr/libexec/sssd/sssd_be --domain default }}} == How do I track work-in-progress of other developers? == Most of the core SSSD developers publish their work in progress patches in topic branches of git repositories on http://fedorapeople.org The web interface for the git repositories are available at {{{ http://fedorapeople.org/gitweb?p=USERNAME/public_git/REPO_NAME }}} where USERNAME is the FAS user name of the developer and in the particular case of REPO_NAME is usually sssd.git To add the repository as a git remote, issue the following: {{{ git remote add REMOTE_NAME git://fedorapeople.org/home/fedora/USERNAME/public_git/REPO_NAME.git git fetch REMOTE_NAME }}} You can then see all the branches you are tracking with: {{{ git branch -a }}} Or for a particular remote: {{{ git branch -a | grep remotes/REMOTE_NAME }}} If you'd like to publish your work in the fedorapeople.org repo, follow [https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#BETA_git_hosting_support the guide] on the Fedora Project wiki - == Why does make check take so long? == By default, the SSSD tests are performed in the build directory. Some of the unit tests, in particular the sysdb test generate a lot of disk activity and the test runs might take a long time if executed on local disk. One solution is to use the {{{--with-test-dir}}} parameter which specifies where the tests are creating their temporary files. Configuring the test dir to use the in memory tmpfs filesystem located in {{{/dev/shm}}} will mitigate the disk activity and improve the execution time. {{{ ./configure --with-test-dir=/dev/shm make check }}}