1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
<listitem>
<para>
SSSD supports two representations for specifying the debug level. The
simplest is to specify a decimal value from 0-9, which represents
enabling that level and all lower-level debug messages. The more
comprehensive option is to specify a hexadecimal bitmask to enable or
disable specific levels (such as if you wish to suppress a level).
</para>
<para>
Please note that each SSSD service logs into its own log
file. Also please note that enabling <quote>debug_level</quote>
in the <quote>[sssd]</quote> section only enables debugging just
for the sssd process itself, not for the responder or provider
processes. The <quote>debug_level</quote> parameter should be
added to all sections that you wish to produce debug logs from.
</para>
<para>
In addition to changing the log level in the config file using
the <quote>debug_level</quote> parameter, which is persistent, but
requires SSSD restart, it is also possible to change the debug level
on the fly using the
<citerefentry>
<refentrytitle>sss_debuglevel</refentrytitle>
<manvolnum>8</manvolnum>
</citerefentry>
tool.
</para>
<para>
Currently supported debug levels:
</para>
<para>
<emphasis>0</emphasis>,
<emphasis>0x0010</emphasis>:
Fatal failures. Anything that would prevent SSSD from starting up or
causes it to cease running.
</para>
<para>
<emphasis>1</emphasis>,
<emphasis>0x0020</emphasis>:
Critical failures. An error that doesn't kill SSSD, but one that
indicates that at least one major feature is not going to work
properly.
</para>
<para>
<emphasis>2</emphasis>,
<emphasis>0x0040</emphasis>: Serious failures. An error announcing
that a particular request or operation has failed.
</para>
<para>
<emphasis>3</emphasis>,
<emphasis>0x0080</emphasis>: Minor failures. These are the errors that
would percolate down to cause the operation failure of 2.
</para>
<para>
<emphasis>4</emphasis>,
<emphasis>0x0100</emphasis>: Configuration settings.
</para>
<para>
<emphasis>5</emphasis>,
<emphasis>0x0200</emphasis>: Function data.
</para>
<para>
<emphasis>6</emphasis>,
<emphasis>0x0400</emphasis>: Trace messages for operation functions.
</para>
<para>
<emphasis>7</emphasis>,
<emphasis>0x1000</emphasis>: Trace messages for internal control
functions.
</para>
<para>
<emphasis>8</emphasis>,
<emphasis>0x2000</emphasis>: Contents of function-internal variables
that may be interesting.
</para>
<para>
<emphasis>9</emphasis>,
<emphasis>0x4000</emphasis>: Extremely low-level tracing information.
</para>
<para>
<emphasis>9</emphasis>,
<emphasis>0x20000</emphasis>: Performance and statistical data,
please note that due to the way requests are processed internally the
logged execution time of a request might be longer than it actually
was.
</para>
<para>
<emphasis>10</emphasis>,
<emphasis>0x10000</emphasis>: Even more low-level libldb tracing
information. Almost never really required.
</para>
<para>
To log required bitmask debug levels, simply add their numbers together
as shown in following examples:
</para>
<para>
<emphasis>Example</emphasis>: To log fatal failures, critical failures,
serious failures and function data use 0x0270.
</para>
<para>
<emphasis>Example</emphasis>: To log fatal failures, configuration
settings, function data, trace messages for internal control functions
use 0x1310.
</para>
<para>
<emphasis>Note</emphasis>: The bitmask format of debug levels was
introduced in 1.7.0.
</para>
<para>
<emphasis>Default</emphasis>: 0x0070 (i.e. fatal, critical and serious
failures; corresponds to setting 2 in decimal notation)
</para>
</listitem>
|
