#51 reporting bugs: Hint on increasing the timeout
Merged 6 years ago by jhrozek. Opened 6 years ago by jhrozek.
SSSD/ jhrozek/docs master  into  master

file modified
+20
@@ -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.

what about mentioning also calling teardown_watchdog?

gdb process `pgrep sssd_nss$` -ex "p teardown_watchdog()"

I think both approaches are good to advertise

BTW please rebase on top of current master so we will not have merge commit

rebased onto 6087a3b384a9a9cb4fdf5b4dcbbfd8225ebc94fd

6 years ago

rebased onto 7edddd93c429895272abe5bb9ca031250bf52ce9

6 years ago

rebased onto 15cc90b5679ac9120a5d0a978d8c7311bb0182f1

6 years ago

rebased onto 4adfb23

6 years ago

Two weeks without some additional comment -> merging

Pull-Request has been merged by jhrozek

6 years ago
Metadata