ubuntu-phone team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

On Mon, Jan 13, 2014 at 09:51:38AM +0200, Michał Sawicz wrote:
> On 12.01.2014 21:48, Steve Langasek wrote:
> >Ok.  I don't see any reason that the kill timeout would be insufficient for
> >this case.  Tested in a user session with the attached python program and
> >upstart job, and I get the expected results in
> >~/.cache/upstart/kill-test.log.

> >Maybe the kill timeout isn't high enough for apport to finish processing the
> >unity8 core.

> Yup, it's just too big for apport to finish in time.

> >Is this reproducible if you raise the timeout higher than 30 sec?

> Not sure I understand your question. That's exactly what we did - we
> bumped the timeout in unity8-autopilot package to make sure that we
> get exit .crash files during ap testing.

Evan's original comment was:

> Didier informs me that they were seeing a lot of crashes in unity8 with a
> smashed stacktrace.  They realised the dying unity process was getting
> reaped and restarted by upstart while still being processed by apport
> because it was taking a long time to collect and process the core file. 
> They set a timeout 30s (data/unity8.override in unity8-autopilot), which
> seemed to work around the problem, but perhaps that value is being
> exceeded.

So the question is, is 30 seconds actually long enough for apport to finish
crash-handling of unity8?  I don't know the answer to this.  It sounds like
Evan is still seeing some bad data somewhere, but it's not clear to me where
this is.  But if there's any doubt, raising the kill timeout further should
be safe, since it only slows things down in the case where unity8 isn't
dying on its own (because of apport), and we want that to be as slow as it
needs to be to get the job done.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@xxxxxxxxxx                                     vorlon@xxxxxxxxxx

Attachment: signature.asc
Description: Digital signature