use 'modern' logging style

This commit is contained in:
Pierangelo Masarati 2008-02-16 11:47:32 +00:00
parent 2df4675ac3
commit 63b0e665ad
3 changed files with 4 additions and 4 deletions

View File

@ -261,7 +261,7 @@ bound to the slave will also exist on the master. If that DN does not have
update privileges on the master, nothing will happen.
You will need to restart the slave after these changes. Then, if you are using
{{loglevel 256}}, you can monitor an {{ldapmodify}} on the slave and the master.
{{loglevel stats}} (256), you can monitor an {{ldapmodify}} on the slave and the master.
Now start an {{ldapmodify}} on the slave and watch the logs. You should expect
something like:

View File

@ -90,7 +90,7 @@ H2: Debugging {{slapd}}(8)
After reading through the above sections and before e-mailing the OpenLDAP lists, you
might want to try out some of the following to track down the cause of your problems:
* Loglevel 256 is generally a good first loglevel to try for getting
* Loglevel stats (256) is generally a good first loglevel to try for getting
information useful to list members on issues
* Running {{slapd -d -1}} can often track down fairly simple issues, such as
missing schemas and incorrect file permissions for the {{slapd}} user to things like certs

View File

@ -111,7 +111,7 @@ H2: Logging
H3: What log level to use
The default of {{loglevel 256}} is really the best bet. There's a corollary to
The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to
this when problems *do* arise, don't try to trace them using syslog.
Use the debug flag instead, and capture slapd's stderr output. syslog is too
slow for debug tracing, and it's inherently lossy - it will throw away messages when it
@ -131,7 +131,7 @@ and attribute {{foo}} does not have an equality index. If you see a lot of these
messages, you should add the index. If you see one every month or so, it may
be acceptable to ignore it.
The default syslog level is 256 which logs the basic parameters of each
The default syslog level is stats (256) which logs the basic parameters of each
request; it usually produces 1-3 lines of output. On Solaris and systems that
only provide synchronous syslog, you may want to turn it off completely, but
usually you want to leave it enabled so that you'll be able to see index