This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: how to discover description of error which terminated run
- From: Mark Wielaard <mjw at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: John Lumby <johnlumby at hotmail dot com>, systemtap maillist <systemtap at sourceware dot org>
- Date: Fri, 07 Dec 2012 11:06:37 +0100
- Subject: Re: how to discover description of error which terminated run
- References: <1354805036.18914.ezmlm@sourceware.org> <COL116-W141FD695CAB035A5D8C81A3450@phx.gbl> <y0m624eoj2q.fsf@fche.csb>
On Thu, 2012-12-06 at 18:29 -0500, Frank Ch. Eigler wrote:
> johnlumby wrote:
>
> > [...] What surprises me is that the run continued for a full 0.1
> > seconds (over 4000 lines of output) after this message was logged
> > before it shut itself down. [...]
>
> The intent is not to lose information unnecessarily; the transport of
> that queued information is lightweight enough not to cause overload.
That and we prioritize reporting warning/error messages. When there are
messages from the kernel to user space then warning/errors get reported
first, even when some other messages might still be pending to make sure
errors are always presented to the user. Which in this case made it
harder for the user to spot the error, because we were also able deliver
all the normal messages after reporting the error... :{
> >[...] Makes me wonder - is there some way of directing error
> > messages such as this to some other channel rather than interspersing
> > them into the run output. Or else at least making them more distinctive.
>
> I believe errors/warnings already go to stderr as opposed to stdout.
> I opened PR14927 to make them even more visible. (Want to give coding
> that up a try? We'll help!)
O, color coded error/warnings! Nice idea.
Thanks,
Mark