Bug 3510

Summary:	danny hangs fetching for
Product:	[Build System, Metadata & Runtime] BitBake	Reporter:	Flihp <flihp>
Component:	bitbake	Assignee:	Richard Purdie <richard.purdie>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	minor
Priority:	Low	CC:	poky.bs.watcher, poky.watcher, ross.burton, sgw
Version:	1.3
Target Milestone:	1.3.1
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	---

Description Flihp 2012-11-28 21:36:09 UTC

Building danny from the release tarball hung on me today using an existing OE download directory.  The hang left a bunch of python bitbake processes laying about, one with a 1.5 hour lifetime.  Attempts to kill this process turned it into a zombie for some reason.  Restarting the build caused it to hang again.

At this point I took a look in the download directory and noticed the relevant source tarball was present, it's hash checked out but there was a .lock file as well (the only one in the directory).  Removing the lock file and the source tarball freed things up and the build completed.

In an attempt to repro this I tried to recreate a .lock file in downloads.  This was unsuccessful and I wasn't able to repro the hang.  This is a pretty weak bug report but it was recommended on IRC that I create one to preserve data.

Comment 1 Ross Burton 2012-12-03 12:06:41 UTC

Assigning to Richard as this isn't Danny-specific.

Comment 2 Richard Purdie 2012-12-05 14:43:24 UTC

This sounds like the zombie process continued to own the lock file. The trouble is going to be reproducing that problem since until we can do that, we're just having to guess where the process was hung.

Having the data in the bugzilla is useful since it allows us to see if this was a "one-off" or that people are seeing a lot of this so thanks for reporting it. I'm going to close it as worksforme since we can't reproduce but if others see this please reopen and lets see if we can spot any patterns.