[OE-core] Yocto-2.2 build failures on Ubuntu 14.04.5 & 16.04.x hosts due to crash of unity-settings-daemon followed by restart of lightdm
srikanth krishnakar
skrishnakar at gmail.com
Mon Dec 26 13:29:48 UTC 2016
Hello Richard,
bitbake | cat shows that when this logout happened during build, log file
captured below packages in process:
--------------------------------------------------------------------------------------------
NOTE: Running task 1886 of 4212
(/home/builder/poky/meta/recipes-graphics/xorg-proto/kbproto_1.0.7.bb:
do_packagedata)
NOTE: recipe kbproto-1_1.0.7-r0: task do_packagedata: Started
NOTE: recipe kbproto-1_1.0.7-r0: task do_packagedata: Succeeded
NOTE: Running task 1887 of 4212
(/home/builder/poky/meta/recipes-support/libffi/libffi_3.2.1.bb:do_package)
NOTE: recipe ncurses-6.0+20160625-r0: task do_package: Started
NOTE: recipe libffi-3.2.1-r0: task do_package: Started
NOTE: recipe libffi-3.2.1-r0: task do_package: Succeeded
NOTE: Running task 1888 of 4212
(/home/builder/poky/meta/recipes-support/libffi/libffi_3.2.1.bb:
do_packagedata)
NOTE: recipe libffi-3.2.1-r0: task do_packagedata: Started
NOTE: recipe libffi-3.2.1-r0: task do_packagedata: Succeeded
NOTE: Running task 1889 of 4212
(/home/builder/poky/meta/recipes-extended/bzip2/bzip2_1.0.6.bb:do_package)
NOTE: recipe bzip2-1.0.6-r5: task do_package: Started
-----------------------------------------------------------------------------------------------
Also there was a crash file generated in "/var/crash" folder:
/var/crash/_usr_lib_accountsservice_accounts-daemon.0.crash
That has following information in it:
-------------------------------------------------------------------------------------------------
ProblemType: Crash
Architecture: amd64
Date: Mon Dec 26 18:23:22 2016
DistroRelease: Ubuntu 14.04
ExecutablePath: /usr/lib/accountsservice/accounts-daemon
ExecutableTimestamp: 1478200365
ProcCmdline: /usr/lib/accountsservice/accounts-daemon
ProcCwd: /
ProcEnviron:
ProcMaps:
00400000-00426000 r-xp 00000000 08:01 2626520
/usr/lib/accountsservice/accounts-daemon
00625000-00628000 r--p 00025000 08:01 2626520
/usr/lib/accountsservice/accounts-daemon
00628000-00629000 rw-p 00028000 08:01 2626520
/usr/lib/accountsservice/accounts-daemon
024aa000-0252a000 rw-p 00000000 00:00 0
[heap]
7fe460000000-7fe460022000 rw-p 00000000 00:00 0
7fe460022000-7fe464000000 ---p 00000000 00:00 0
7fe464000000-7fe464021000 rw-p 00000000 00:00 0
7fe464021000-7fe468000000 ---p 00000000 00:00 0
7fe469f56000-7fe469f60000 r-xp 00000000 08:01 1839849
/lib/x86_64-linux-gnu/libnss_files-2.19.so
7fe469f60000-7fe46a15f000 ---p 0000a000 08:01 1839849
/lib/x86_64-linux-gnu/libnss_files-2.19.so
7fe46a15f000-7fe46a160000 r--p 00009000 08:01 1839849
/lib/x86_64-linux-gnu/libnss_files-2.19.so
...
...
7fe474b3e000-7fe474b40000 rw-p 00000000 00:00 0
7fe474b40000-7fe474b41000 r--p 00022000 08:01 1839750
/lib/x86_64-linux-gnu/ld-2.19.so
7fe474b41000-7fe474b42000 rw-p 00023000 08:01 1839750
/lib/x86_64-linux-gnu/ld-2.19.so
7fe474b42000-7fe474b43000 rw-p 00000000 00:00 0
7ffcaca64000-7ffcaca85000 rw-p 00000000 00:00 0
[stack]
7ffcacaf5000-7ffcacaf7000 r--p 00000000 00:00 0
[vvar]
7ffcacaf7000-7ffcacaf9000 r-xp 00000000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
ProcStatus:
Name: accounts-daemon
State: D (disk sleep)
Tgid: 1248
Ngid: 0
Pid: 1248
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups: 0
NStgid: 1248
NSpid: 1248
NSpgid: 795
NSsid: 795
VmPeak: 302404 kB
VmSize: 302368 kB
VmPin: 0 kB
VmHWM: 10128 kB
VmRSS: 4464 kB
VmData: 221944 kB
VmStk: 136 kB
VmExe: 152 kB
VmLib: 10140 kB
VmPTE: 200 kB
VmPMD: 12 kB
VmSwap: 2976 kB
HugetlbPages: 0 kB
Threads: 3
SigQ: 0/31670
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180004002
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 152
nonvoluntary_ctxt_switches: 2
Signal: 7
Uname: Linux 4.4.0-57-generic x86_64
UserGroups:
CoreDump: base64
-------------------------------------------------------------------------------------------------
My machine is:
*Quad-Core:* (0-8)
---------------------------------------
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
-----
$ cat /proc/meminfo
MemTotal: 8132472 kB
----------------------------------------
When I checked free memory just before the logout was about "125MB" out of
8GB RAM.
NOTE: The Ubuntu-14.04.4 that had older graphics stack seem to work
normally without any issue. The "ubuntu-14.04.5" & "16.04" came with latest
graphics stack & kernel with removal of non-opensource fglrx drivers.
Thanks for your patience!
--
Regards,
Srikant
On Mon, Dec 26, 2016 at 4:28 PM, srikanth krishnakar <skrishnakar at gmail.com>
wrote:
> Hello Richard,
>
> Sure, watching is best thing we can do, but it happens somewhere after
> 2900 tasks i.e just after linux-yocto.
> Screen recorders usually ask for file name and destination folder for
> saving the file, will try to see if it works as you said.
> "bitbake | cat" is the best method that we can get info from.
>
> The issue is noticeable only in ubuntu (unity) desktop's and not in
> Kubuntu (KDE), Ubuntu-gnome (Gnome-3) or Xubuntu (XFCE) desktops.
>
> Will fetch more details as per your suggestion.
>
> Thank you !
>
> On Mon, Dec 26, 2016 at 4:06 PM, Richard Purdie <richard.purdie@
> linuxfoundation.org> wrote:
>
>> On Mon, 2016-12-26 at 15:11 +0530, srikanth krishnakar wrote:
>> > Environment: Ubuntu-14.04.5/16.04.1 (64-bit)
>> > Yocto build: qemuarm
>> > Target image: core-image-sato
>> > Error nature: The lightdm restarts on its own and logs out by killing
>> > processes running and brings up a login UI.
>> >
>> >
>> > We have been observing yocto-2.2 build failures on Ubuntu 14.04.5 and
>> > Ubuntu-16.04.1 hosts due to restart of "lightdm" (Light Desktop
>> > Manager) that is triggered by crash of "unity-settings-daemon", we
>> > couldn't figure out any workaround so far to overcome the issue. The
>> > build goes fine in the beginning but eventually the unity desktop
>> > logs out and kills all the processes running in the user session
>> > (including bitbake) and lands us into "Login screen" and when we
>> > login its a new session where as the bitbake running in previous
>> > session is killed and we need to continue the build. This is
>> > happening consistently when the user logs into desktop via lightdm
>> > and triggers a build.
>> >
>> > Another interesting thing to notice is the build goes fine if we
>> > connect to host via. SSH session and invoke a bitbake build. We are
>> > suspecting on unity-settings-daemon that is crashing consistently and
>> > is evident from the ".xsession-errors" log file as shown below:
>> >
>> > builder at ubuntu:~$ cat .xsession-errors.old
>> > Script for ibus started at run_im.
>> > Script for auto started at run_im.
>> > Script for default started at run_im.
>> > init: Disconnected from notified D-Bus bus
>> > init:"unity-settings-daemon main process (2076) terminated with
>> > status 1"
>> > init: indicator-bluetooth main process (2212) killed by TERM signal
>> > init: indicator-power main process (2214) killed by TERM signal
>> > init: indicator-datetime main process (2215) killed by TERM signal
>> > init: indicator-printers main process (2222) killed by TERM signal
>> > init: indicator-session main process (2245) killed by TERM signal
>> > init: indicator-application main process (2270) killed by TERM signal
>> >
>> > Corresponding unity-settings-daemon bug reported in Launchpad:
>> >
>> > https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/
>> > 1546641
>> >
>> > Would anyone kindly confirm the logout behaviour during bitbake
>> > process on Ubuntu-14.04.5 & Ubuntu-16.04.1 ? Since Yocto 2.2 mentions
>> > both Ubuntu-14.04 & 16.04 as supported distributions this blocker
>> > issue must be resolved at earliest.
>> >
>> > Appreciate your Inputs !
>>
>> What would really help is knowing what recipe is being built when this
>> happens. There are a few ways you might be able to figure this out:
>>
>> a) Watching the screen to see which recipes were building when it
>> happens
>> b) Perhaps using some kind of screen recorder to automate this, you'd
>> be able to review the recording to see when it breaks
>> c) Looking at the bitbake/build logs to see what it was doing when the
>> build broke (assuming bitbake stops when the session dies).
>>
>> "bitbake | cat" can provide better output for this since it will
>> produce a scrolling log rather than the more interactive UI.
>>
>> Once you find the problematic recipe, a "bitbake XXX -c clean; bitbake
>> XXX" should hopefully reproduce this more easily.
>>
>> Cheers,
>>
>> Richard
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161226/fad62bf5/attachment-0002.html>
More information about the Openembedded-core
mailing list