On Fri, Jan 10, 2014 at 8:04 PM, Steve Langasek <steve.langa...@canonical.com> wrote: > On Fri, Jan 10, 2014 at 10:10:14AM +0000, Evan Dandrea wrote: >> There's a deeper problem here. 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. > >> We need a better solution than increasing a timeout. James, does >> upstart provide us with a better mechanism for telling it to not kill >> a process in this state? Can we add one if not? :) > > I don't see how this analysis can be correct. upstart receives no signal > from the kernel that the process has died until after the core handler is > finished, and if the unity8 process has died with a segfault there's no > process for upstart to kill anyway - so the kill timeout can't be related > here. > > A syslog from the time of one of these failures, with 'initctl log-priority > info', may be enlightening.
Wonder if we should set our log priority to that level for all our automated image testing? Thoughts? > > -- > 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/ > slanga...@ubuntu.com vor...@debian.org -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp