Hi,

On 2023-03-16 23:52:04 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > I got sidetracked trying to make slapd stop any and all syslog access, but 
> > it
> > doesn't look like that's possible. But working on commiting the logfile-only
> > approach now. Planning to backpatch this, unless somebody protests very 
> > soon.
> 
> Sadly, buildfarm seems to be having some indigestion with this ...

Unfortunately even just slightly older versions don't have the logfile-only
option :(.

For a bit I thought we were out of options, because 'loglevel 0' works, but
I was not seeing any contents in the logfile we specify. But as it turns out,
the logfile we (before this patch already) specify, don't contain anything
ever, because:
       logfile <filename>
              Specify  a  file  for  recording  slapd  debug messages. By 
default these messages only go to stderr, are not recorded anywhere else, and 
are
              unrelated to messages exposed by the loglevel configuration 
parameter. Specifying a logfile copies messages to both stderr and the logfile.
and
       loglevel <integer> [...]
              Specify  the  level at which debugging statements and operation 
statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4

yet using logfile-only does prevent things from ending up in syslog.

Because it's not at all confusing that a 'loglevel' option doesn't influence
at all what ends up in the file controlled by 'logfile'.


Given that 'loglevel 0' works and doesn't actually reduce the amount of
logging available, that seems to be the way to go.


Iff we actually want slapd logging, the stderr logging can be turned on (and
potentially redirected to a logfile via logfile or redirection). But
unfortunately it seems that the debug level can only be set on the server
commandline. And has a significant sideeffect:
       -d debug-level
              Turn on debugging as defined by debug-level.  If this option is 
specified, even with a zero argument, slapd will  not  fork  or  disassociate
              from  the invoking terminal

Which means the server can't be started anymore as we do currently do, we'd
have to use IPC::Run::start.  I hacked that together locally, but that's more
than I think I can get right at my current level of tiredness.


So unless somebody has a better idea, I'm gonna replace 'logfile-only on' with
'loglevel 0' for now. I also am open to reverting and trying again tomorrow.

Greetings,

Andres Freund


Reply via email to