| |
@@ -103,6 +103,26 @@
|
| |
|
| |
Then attach the core file and the backtrace.
|
| |
|
| |
+ When connecting to a sssd process with ``gdb``, you should increase the
|
| |
+ ``timeout`` option in the debugged process's section up from its default
|
| |
+ value, such as::
|
| |
+
|
| |
+ [domain/test]
|
| |
+ id_provider=ldap
|
| |
+ ....
|
| |
+ timeout = 300
|
| |
+
|
| |
+ If you don't do this, chances are that ``gdb`` will be interrupted by SSSD's
|
| |
+ internal watchdog (which manifests as SSSD receiving ``SIGRT``) before you
|
| |
+ can catch the error you're debugging.
|
| |
+
|
| |
+ Alternatively, you can disable the watchdog from inside the gdb session::
|
| |
+
|
| |
+ gdb process `pgrep sssd_be` -ex "p teardown_watchdog()"
|
| |
+
|
| |
+ This has the advantage of not having to restart the sssd, on the other hand,
|
| |
+ the watchdog is also disabled for the single gdb session only.
|
| |
+
|
| |
Mind your privacy
|
| |
-----------------
|
| |
|
| |
I've seen two cases where users tried to debug a sssd process, but the gdb session kept being interrupted by SIGRT before they could get any useful info. Point out the internal watchdog to enable the gdb session to last longer.