git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [Hang] t5562 subtest 8 on NonStop
@ 2019-02-08 12:23 Randall S. Becker
  2019-02-09 20:22 ` Randall S. Becker
  0 siblings, 1 reply; 2+ messages in thread
From: Randall S. Becker @ 2019-02-08 12:23 UTC (permalink / raw)
  To: git

Hi All,

We have suddenly encountered a hung git-http-backend in t5562 in the NonStop
port. This is a new problem not seen before on the platform, surprisingly. I
am wondering whether this is a result of not actually having an apache2
server on-board. Is that a possibility and can that sub-test be bypassed if
no apache2 is detected?

We also had subtest 15 and I am investigating, but it may depend on 8's data
(I had to kill the git-http-backend process, so maybe that's why).

Thanks,
Randall


^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: [Hang] t5562 subtest 8 on NonStop
  2019-02-08 12:23 [Hang] t5562 subtest 8 on NonStop Randall S. Becker
@ 2019-02-09 20:22 ` Randall S. Becker
  0 siblings, 0 replies; 2+ messages in thread
From: Randall S. Becker @ 2019-02-09 20:22 UTC (permalink / raw)
  To: git

On February 8, 2019 7:23, I wrote:
> We have suddenly encountered a hung git-http-backend in t5562 in the
> NonStop port. This is a new problem not seen before on the platform,
> surprisingly. I am wondering whether this is a result of not actually
having an
> apache2 server on-board. Is that a possibility and can that sub-test be
> bypassed if no apache2 is detected?
> 
> We also had subtest 15 and I am investigating, but it may depend on 8's
data
> (I had to kill the git-http-backend process, so maybe that's why).

I'm back to investigating subtest 8 hanging after dealing with the /dev/zero
thing. What we end up with two git processes, a git-http-backend, a perl,
and a few shell processes. The act.err file had:

fatal: request ended in the middle of the gzip stream

Which went through die() and should have unwound the whole thing, but
didn't. The git-http-backend is waiting to clean up children and each git is
polling for input. It seems like SIGCHLD did not get back through the
process that started it, or its parent - but I don't quite follow the flow
in this test. I have seen the perl port not like SIGCHLD sometimes, so that
might be what is going on. Is it possible to skip the hanging subtest during
a whole test run? We don't really have anyone using the http backend on
platform (SSH is the generally preferred method to get to git on box), so I
am tempted to ignore the ones that hang as conditional known breakages, if
that is possible, so that we can get our CI builds back in operation.
Thoughts? Advice?

Thanks,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-02-09 20:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08 12:23 [Hang] t5562 subtest 8 on NonStop Randall S. Becker
2019-02-09 20:22 ` Randall S. Becker

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).