Il 04/04/2013 16:54, Laszlo Ersek ha scritto:
> Side note: strictly in theory, this would result in two vfprintf()
> calls. The message log would remain "record oriented", but (again, in
> theory) another thread *might* get interleaved and mess up our format
> with a parallel call to error_report()
On 02/01/13 15:53, Seiji Aguchi wrote:
> /*
> * Print an error message to current monitor if we have one, else to stderr.
> * Format arguments like sprintf(). The result should not contain
> @@ -207,6 +296,7 @@ void error_report(const char *fmt, ...)
> {
> va_list ap;
>
> +error_
On Mon, Feb 04, 2013 at 03:58:29PM +, Seiji Aguchi wrote:
> > Also remember that management tools can pass a pipe as stderr when starting
> > QEMU, and
> > then they can add their preferred timestamping/log formatting outside of
> > QEMU.
>
> To get an exact timestamp, qemu should supply it
> > [TODO]
> > Other functions below are used to output error messages in qemu.
> > - qerror_report() is called in many source codes.
>
> Not a problem, it ends up in qerror_print(), which calls error_report().
Thanks.
>
> > - fprintf() is called in vl.c.
>
> All over the place, not just vl.
> > Do we really want to add timestamps to error messages unconditionally?
> > I don't doubt it's useful in your scenario, but most of the time it's
> > just annoying clutter.
>
> Agreed, I think it should be an option.
OK. I will add the timestamp as an option.
> Also remember that management
Stefan Hajnoczi writes:
> On Sat, Feb 02, 2013 at 08:31:45AM +0100, Markus Armbruster wrote:
>> Seiji Aguchi writes:
>>
>> > [Issue]
>> > When we offer a customer support service and a problem happens
>> > in a customer's system, we try to understand the problem by
>> > comparing what the cus
On Sat, Feb 02, 2013 at 08:31:45AM +0100, Markus Armbruster wrote:
> Seiji Aguchi writes:
>
> > [Issue]
> > When we offer a customer support service and a problem happens
> > in a customer's system, we try to understand the problem by
> > comparing what the customer reports with message logs of
Seiji Aguchi writes:
>> > Are gmtime() + strftime() unsuitable for some reason?
>>
>> They are not async-signal safe, so they are not usable in between a
>> fork() and exec*(). Libvirt avoids them because it DOES log
>> information including timestamps in between fork/exec (and prior to
>> writ
Seiji Aguchi writes:
> [Issue]
> When we offer a customer support service and a problem happens
> in a customer's system, we try to understand the problem by
> comparing what the customer reports with message logs of the
> customer's system.
>
> In this case, we often need to know when the pro
On 02/01/2013 11:28 AM, Laszlo Ersek wrote:
> Hello Seiji-san,
>
> On 02/01/13 15:53, Seiji Aguchi wrote:
>
>> A logic calculating a time is copied from libvirt, src/util/virtime.c.
>
>> +static void error_print_timestamp(void)
>
> Are gmtime() + strftime() unsuitable for some reason?
They are
> > Are gmtime() + strftime() unsuitable for some reason?
>
> They are not async-signal safe, so they are not usable in between a
> fork() and exec*(). Libvirt avoids them because it DOES log information
> including timestamps in between fork/exec (and prior to
> writing libvirt's virtime.c, we
Hi Laszlo,
Thank you for reviewing my patch!
I will update my patch in accordance with your comment, using gmtime() +
strftime() and gettimeofday().
Seiji
Hello Seiji-san,
On 02/01/13 15:53, Seiji Aguchi wrote:
> A logic calculating a time is copied from libvirt, src/util/virtime.c.
> +static void error_print_timestamp(void)
Are gmtime() + strftime() unsuitable for some reason?
Also, since the timestamp is ultimately printed with millisecond
res
[Issue]
When we offer a customer support service and a problem happens
in a customer's system, we try to understand the problem by
comparing what the customer reports with message logs of the
customer's system.
In this case, we often need to know when the problem happens.
But, currently, there
14 matches
Mail list logo
