Re: [PATCH 6/7] trace: disable key after write error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 04, 2016 at 01:45:11PM -0700, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > If we get a write error writing to a trace descriptor, the
> > error isn't likely to go away if we keep writing. Instead,
> > you'll just get the same error over and over. E.g., try:
> >
> >   GIT_TRACE_PACKET=42 git ls-remote >/dev/null
> >
> > You don't really need to see:
> >
> >   warning: unable to write trace for GIT_TRACE_PACKET: Bad file descriptor
> >
> > hundreds of times. We could fallback to tracing to stderr,
> > as we do in the error code-path for open(), but there's not
> > much point. If the user fed us a bogus descriptor, they're
> > probably better off fixing their invocation. And if they
> > didn't, and we saw a transient error (e.g., ENOSPC writing
> > to a file), it probably doesn't help anybody to have half of
> > the trace in a file, and half on stderr.
> 
> Yes, I think I like this better than "we cannot open the named file,
> so let's trace into standard error stream" that is done in the code
> in the context of [3/7].  We should do the same over there.

Yeah, I was tempted to strip that out, too. I'll look into preparing a
patch on top.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]