Whereas VLOG_FATAL() eventually calls exit(1), VLOG_ABORT()
eventually calls abort(). The key difference is that abort()
will cause a "monitor" process to restart, where exit(1) will
cause it to exit along with the monitored process.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This will be more useful later when we introduces "worker" subprocesses.
I don't have any current plans to introduce threading, but I can't
think of a disadvantage to wording this in a general manner.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This commit converts two rate-limiters in the tree to use the library.
I intend to use the library elsewhere in the future.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Change the default timestamp for console and file logs to
UTC in a format that satisfies timestamp requirements in RFC 5424.
Also, add the ability for ovs-appctl to log timestamps in UTC.
Bug #9052.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
Users should be able to find out what a log level means without reading
source code comments, so this seems like a better place for it.
Reported-by: David Tsai <dtsai@nicira.com>
Until now, "emer" has effectively been "off" because no messages were ever
logged at "emer" level. Justin points out that it is useful to use "emer"
for messages that indicate a fatal error. This commit makes that change
and adds a new "off" level to really turn off all logging to a facility.
When a message is suppressed by vlog ratelimiting, and then that message
occurs again much later, sometimes we get messages like this:
Dropped 4 log messages in last 8695 seconds due to excessive rate
It seems pretty clear in this case that in fact we just didn't get that
kind of message for most of that 8695 seconds. This commit improves the
message by adding a little more detail, e.g.:
Dropped 4 log messages in last 8695 seconds (most recently, 6697 seconds
ago) due to excessive rate.
Bug #2144.
sparse warns if a non-static variable with external linkage has an
initializer at first declaration, because it suspects that it should be
static instead. Generally it's correct, but not in these cases, so add
a redundant declaration to suppress the warning.
The suppress warnings look like:
../ofproto/connmgr.c:40:1: warning: symbol 'VLM_connmgr' was not declared. Should it be static?
../ofproto/collectors.c:31:1: warning: symbol 'vlog_module_ptr_collectors' was not declared. Should it be static?
../ofproto/connmgr.c:43:1: warning: symbol 'counter_ofconn_stuck' was not declared. Should it be static?
These macros expanded the LEVEL argument without protecting it with
parentheses, which meant that an argument like 'cond ? VLL_DBG : VLL_WARN'
did not have the desired effect (and caused a GCC warning).
This commit fixes the problem and avoids expanding LEVEL more than once,
too.
Until now, the collection of vlog modules supported by a given OVS program
was not specific to that program. That means that, for example, even
though ovs-dpctl does not have anything to do with jsonrpc, it still has
a vlog module for it. This is confusing, at best.
This commit fixes the problem on some systems, in particular on ones that
use GCC and the GNU linker. It uses the feature of the GNU linker
described in its manual as:
If an orphaned section's name is representable as a C identifier then
the linker will automatically see PROVIDE two symbols: __start_SECNAME
and __end_SECNAME, where SECNAME is the name of the section. These
indicate the start address and end address of the orphaned section
respectively.
Systems that don't support these features retain the earlier behavior.
This commit also fixes the annoyance that modifying lib/vlog-modules.def
causes all sources files that #include "vlog.h" to recompile.
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
