[ovs-dev] [PATCH 1/4] logging: Lower loggging level for coverage messages due to slow poll loops

Ben Pfaff blp at nicira.com
Fri Sep 11 17:05:54 UTC 2009


Justin Pettit <jpettit at nicira.com> writes:

> Subject: [PATCH 1/4] logging: Lower loggging level for coverage messages due to slow poll loops

s/loggging/logging/

> By default, many OVS processes keep track of their time through a poll
> loop.  If it takes an unusually long time (measured as some distance
> from the mean), the processes will log stats its been keeping about

its => "it's" or "it has"

> coverage.  It was doing this at level WARN.
>
> On Xen systems, syslog messages written at level INFO and higher are
> written to /var/log/messages synchronously.  

Is there really a difference in syslog behavior depending on log
level?  Should this say something more like: "On Xen systems,
syslog messages are written to /var/log/messages synchronously.
vswitchd sends messages at level INFO and higher to
/var/log/messages."

> This commit lowers the default log level for those coverage messages to
> INFO.  On Xen systems, it raises the default level at which messages are
> written to syslog to WARN.

I think that we should add a comment in coverage.c next to the
vlog call that explains why it's at that level.  Otherwise I'd be
tempted to raise the level at some point.

By the way, I looked at the syslog code in glibc.  You're right,
LOG_NDELAY has no effect on how messages are logged, just on when
the logging socket is opened.

I'm really tempted to say that we shouldn't log to syslog at all
on XenServer.  ovs-vswitchd could get stuck behind another
process that is logging a lot of stuff, for example.  The
interface-reconfigure and vif scripts do a lot of logging to
syslog, for example, and that could delay ovs-vswitchd too.
Logging to our own file doesn't have the same issue.




More information about the dev mailing list