Обсуждение: slapd logs to syslog during tests
Hi, On my buildfarm host (for all my animals) I noted that slapd was by far the biggest contributor to syslog. Even though there's not normally slapd running. It's of course the slapds started by various tests. Would anybody mind if I add 'logfile_only' to slapd's config in LdapServer.pm? That still leaves a few logline, from before the config file parsing, but it's a lot better than all requests getting logged. Obviously I also could reconfigure syslog to just filter this stuff, but it seems that the tests shouldn't spam like that. Greetings, Andres Freund
> On Mar 11, 2023, at 6:37 PM, Andres Freund <andres@anarazel.de> wrote: > > Hi, > > On my buildfarm host (for all my animals) I noted that slapd was by far the > biggest contributor to syslog. Even though there's not normally slapd > running. It's of course the slapds started by various tests. > > Would anybody mind if I add 'logfile_only' to slapd's config in LdapServer.pm? > That still leaves a few logline, from before the config file parsing, but it's > a lot better than all requests getting logged. Makes sense Cheers Andrew
On 2023-03-11 Sa 18:37, Andres Freund wrote:
Hi, On my buildfarm host (for all my animals) I noted that slapd was by far the biggest contributor to syslog. Even though there's not normally slapd running. It's of course the slapds started by various tests. Would anybody mind if I add 'logfile_only' to slapd's config in LdapServer.pm? That still leaves a few logline, from before the config file parsing, but it's a lot better than all requests getting logged. Obviously I also could reconfigure syslog to just filter this stuff, but it seems that the tests shouldn't spam like that.
Hi, Andres,
are you moving ahead with this?
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
On Fri, Mar 17, 2023 at 9:15 AM Andrew Dunstan <andrew@dunslane.net> wrote: > On 2023-03-11 Sa 18:37, Andres Freund wrote: > On my buildfarm host (for all my animals) I noted that slapd was by far the > biggest contributor to syslog. Even though there's not normally slapd > running. It's of course the slapds started by various tests. > > Would anybody mind if I add 'logfile_only' to slapd's config in LdapServer.pm? > That still leaves a few logline, from before the config file parsing, but it's > a lot better than all requests getting logged. > > Obviously I also could reconfigure syslog to just filter this stuff, but it > seems that the tests shouldn't spam like that. > > > Hi, Andres, > > are you moving ahead with this? +1 for doing so. It has befuddled me before that I had to hunt down error messages by tracing system calls[1], and that's useless for readers of CI/BF logs. [1] https://www.postgresql.org/message-id/flat/CA%2BhUKGJdwNiwM5iWXVh050kKw5p3VCMJyoFyCpPbEf6ZNOC1pw%40mail.gmail.com#efe8bb4695171288e4e600391df3f9fa
Hi, On 2023-03-16 16:14:58 -0400, Andrew Dunstan wrote: > are you moving ahead with this? 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. Greetings, Andres Freund
Andres Freund <andres@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 ...
regards, tom lane
Hi,
On 2023-03-16 23:52:04 -0400, Tom Lane wrote:
> Andres Freund <andres@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
notrecorded anywhere else, and are
unrelated to messages exposed by the loglevel configuration parameter. Specifying a logfile copies
messagesto both stderr and the logfile.
and
loglevel <integer> [...]
Specify the level at which debugging statements and operation statistics should be syslogged (currently
loggedto 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,
slapdwill 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
Hi, On 2023-03-16 22:43:17 -0700, Andres Freund wrote: > 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. Did that now. I used the commandline option -s0 instead of loglevel 0, as that prevents even the first message. Regards, Andres