[SSSD] RFC: a wiki page with tips for developers

Jakub Hrozek jhrozek at redhat.com
Mon Apr 16 09:36:18 UTC 2012


Hi,

Some time ago, Stephen mentioned that we might want to create a wiki
page that would contain tips for developers. I think it might be very
useful especially for new contributors. Attached is a draft of the page,
I plan to link it from the "Contribute" page. 

Comments are appreciated.
-------------- next part --------------
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 <path-to-service>}}}. 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
}}}



More information about the sssd-devel mailing list