All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/1] Avoid problem with Git fetcher hanging
@ 2014-02-20 14:55 Peter Kjellerstedt
  2014-02-20 14:55 ` [PATCH 1/1] bitbake: Disable pseudo in runfetchcmd() Peter Kjellerstedt
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Kjellerstedt @ 2014-02-20 14:55 UTC (permalink / raw)
  To: bitbake-devel

This fixes a problem we have had for a long time where a build on rare
occasions hangs. The problem was due to the Git fetcher trying to use
git ls-remote to determine the SHA-1 for a tag. If this happened when
pseudo was active, git (or rather ssh) would hang indefinitely.

//Peter

The following changes since commit 54562006c1327c5b99daa4cc05a3ba7e38412da1:

  image_types.bbclass: Fix tar IMAGE_CMD to not change directories (2014-02-18 08:38:52 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib pkj/no_pseudo_for_git
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pkj/no_pseudo_for_git

Peter Kjellerstedt (1):
  bitbake: Disable pseudo in runfetchcmd()

 bitbake/lib/bb/fetch2/__init__.py | 3 +++
 1 file changed, 3 insertions(+)

-- 
1.8.4



^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [PATCH 1/1] bitbake: Disable pseudo in runfetchcmd()
@ 2014-02-21 10:10 Peter Kjellerstedt
  0 siblings, 0 replies; 10+ messages in thread
From: Peter Kjellerstedt @ 2014-02-21 10:10 UTC (permalink / raw)
  To: Mark Hatle, bitbake-devel

> -----Original Message-----
> From: bitbake-devel-bounces@lists.openembedded.org [mailto:bitbake-
> devel-bounces@lists.openembedded.org] On Behalf Of Mark Hatle
> Sent: den 20 februari 2014 16:43
> To: bitbake-devel@lists.openembedded.org
> Subject: Re: [bitbake-devel] [PATCH 1/1] bitbake: Disable pseudo in
> runfetchcmd()
> 
> On 2/20/14, 8:55 AM, Peter Kjellerstedt wrote:
> > If a fetcher, e.g., git, is run when pseudo is active it will think
> > it is running as root. If it in turn uses ssh (as git does), ssh too
> > will think it is running as root. This will cause it to try to read 
> > root's ssh configuration from /root/.ssh which will fail. If ssh then 
> > needs to ask for credentials it will hang indefinitely as there is 
> > nowhere for it to ask the user for them (and even if there was it 
> > would not access the correct private keys).
> >
> > The solution to the above is to temporarily disable pseudo while
> > executing any fetcher commands. There should be no reason for them 
> > to be executed under pseudo anyway so this should not be a problem.
> >
> > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > ---
> >   bitbake/lib/bb/fetch2/__init__.py | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py
> > index de95074..1c3ee4f 100644
> > --- a/bitbake/lib/bb/fetch2/__init__.py
> > +++ b/bitbake/lib/bb/fetch2/__init__.py
> > @@ -680,6 +680,9 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
> >           if val:
> >               cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
> >
> > +    # Disable pseudo as it may affect ssh, potentially causing it to hang.
> > +    cmd = 'export PSEUDO_DISABLED=1; ' + cmd
> > +
> 
> This may be a reasonable workaround... but is there any way we can
> identify the offending command and create a reproducer for pseudo?

Not sure what that means, but see below.

> It would be nice to identify what the actual problem is -- as 
> something else in the system may encounter it.

So far the only time we have seen it is in get_machine_branch() in 
kernel-yocto.bbclass which is called from do_patch(). We use our 
own kernel which is retrieved from our Git server. The Git server 
requires that one authenticates using a private key. However, when 
ssh (as run by git ls-remote) is run under pseudo it tries to access 
/root/.ssh which fails. As it can't find any keys it then asks for a 
login password instead (I think, there is no prompt or anything from 
ssh) and hangs indefinitely as there is no way to provide the 
password. And even if there had been a way, it would not have worked 
anyway as no such password exist.

The problem only manifests itself very rarely. Yesterday was my 
third opportunity to debug it in a number of months, each time 
getting a little further. Typically during debugging I have then 
done something that makes bitbake continue past the hanging point 
and after that it was no longer possible to trigger the problem. 
However, yesterday I finally managed to create a test case which 
consistently reproduces the problem. Try adding the following to a 
recipe that retrieves from Git and that has a tag= in the SRC_URI:

fakeroot do_lockup() {
	foo="${@ bb.fetch2.Fetch([], d)}"
}
do_lockup[nostamp] = "1"
addtask do_lockup

The second time I run "bitbake -c lockup <recipe>" it hangs, and 
any time after that that I run it again.

> --Mark
> 
> >       logger.debug(1, "Running %s", cmd)
> >
> >       success = False
> >

//Peter



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

end of thread, other threads:[~2014-03-24 12:45 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-20 14:55 [PATCH 0/1] Avoid problem with Git fetcher hanging Peter Kjellerstedt
2014-02-20 14:55 ` [PATCH 1/1] bitbake: Disable pseudo in runfetchcmd() Peter Kjellerstedt
2014-02-20 15:42   ` Mark Hatle
2014-02-22 11:24   ` Richard Purdie
2014-03-20 15:03     ` Olof Johansson
2014-03-20 15:14       ` Richard Purdie
2014-03-21  8:27         ` Olof Johansson
2014-03-22 10:12           ` Richard Purdie
2014-03-24 12:45             ` Olof Johansson
2014-02-21 10:10 Peter Kjellerstedt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.