git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: O_NONBLOCK: should I blame git or ssh?

From
DGDouglas Graham <douglas.graham@ericsson.com>
Date
Sep 9, 2019, 15:52 UTC
Message-ID
<BN8PR15MB302506328B68B266FD0835F8F0B70@BN8PR15MB3025.namprd15.prod.outlook.com>
In-Reply-To
<20190908102839.GC15641@sigill.intra.peff.net>

I think I've just figured out why my workaround works. When ssh sets O_NONBLOCK on stdout, it's setting it on the write side of the pipe that git created. Nothing else writes to that pipe, so this does not cause a problem. Presumably, ssh itself is able to deal with writing to a non-blocking "file description". When ssh sets O_NONBLOCK on stderr, it's setting it on the pipe created by Jenkins. But that's the same pipe that my workaround program does the select() on, so my workaround can compensate. When I run "make | workaround", the write side of *that* pipe is never made non-blocking, and that's the one that make itself writes to.

Ok, I think all mysteries are solved, but I'm still not sure what the moral of the story is. This seems like it could lead to some really difficult to debug problems, but it's not clear to me what the right long-term fix should be. For now, we'll just leave our workaround in place and think about tweaking our makefile to redirect git's stderr.

Previous: Jeff King
Message 5 of 5 in “O_NONBLOCK: should I blame git or ssh?”
  1. Douglas GrahamSep 7, 2019
  2. Jeff KingSep 8, 2019
  3. Douglas GrahamSep 8, 2019
  4. Jeff KingSep 9, 2019
  5. Douglas GrahamSep 9, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.