<div dir="ltr"><font face="monospace, monospace">Hello Richard,</font><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Sure, watching is best thing we can do, but it happens somewhere after 2900 tasks i.e just after linux-yocto. </font></div><div><font face="monospace, monospace">Screen recorders usually ask for file name and destination folder for saving the file, will try to see if it works as you said. </font></div><div><font face="monospace, monospace">"bitbake | cat" is the best method that we can get info from. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The issue is noticeable only in ubuntu (unity) desktop's and not in Kubuntu (KDE), Ubuntu-gnome (Gnome-3) or Xubuntu (XFCE) desktops. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Will fetch more details as per your suggestion. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Thank you !</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 26, 2016 at 4:06 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2016-12-26 at 15:11 +0530, srikanth krishnakar wrote:<br>
> Environment: Ubuntu-14.04.5/16.04.1 (64-bit)<br>
> Yocto build: qemuarm<br>
> Target image: core-image-sato<br>
> Error nature: The lightdm restarts on its own and logs out by killing<br>
> processes running and brings up a login UI. <br>
><br>
><br>
> We have been observing yocto-2.2 build failures on Ubuntu 14.04.5 and<br>
> Ubuntu-16.04.1 hosts due to restart of "lightdm" (Light Desktop<br>
> Manager) that is triggered by crash of "unity-settings-daemon", we<br>
> couldn't figure out any workaround so far to overcome the issue. The<br>
> build goes fine in the beginning but eventually the unity desktop<br>
> logs out and kills all the processes running in the user session<br>
> (including bitbake) and lands us into "Login screen" and when we<br>
> login its a new session where as the bitbake running in previous<br>
> session is killed and we need to continue the build. This is<br>
> happening consistently when the user logs into desktop via lightdm<br>
> and triggers a build. <br>
><br>
> Another interesting thing to notice is the build goes fine if we<br>
> connect to host via. SSH session and invoke a bitbake build. We are<br>
> suspecting on unity-settings-daemon that is crashing consistently and<br>
> is evident from the ".xsession-errors" log file as shown below:<br>
><br>
> builder@ubuntu:~$ cat .xsession-errors.old<br>
> Script for ibus started at run_im.<br>
> Script for auto started at run_im.<br>
> Script for default started at run_im.<br>
> init: Disconnected from notified D-Bus bus<br>
> init:"unity-settings-daemon main process (2076) terminated with<br>
> status 1"<br>
> init: indicator-bluetooth main process (2212) killed by TERM signal<br>
> init: indicator-power main process (2214) killed by TERM signal<br>
> init: indicator-datetime main process (2215) killed by TERM signal<br>
> init: indicator-printers main process (2222) killed by TERM signal<br>
> init: indicator-session main process (2245) killed by TERM signal<br>
> init: indicator-application main process (2270) killed by TERM signal<br>
><br>
> Corresponding unity-settings-daemon bug reported in Launchpad:<br>
><br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>ubuntu/+source/unity-settings-<wbr>daemon/+bug/</a><br>
> 1546641<br>
><br>
> Would anyone kindly confirm the logout behaviour during bitbake<br>
> process on Ubuntu-14.04.5 & Ubuntu-16.04.1 ? Since Yocto 2.2 mentions<br>
> both Ubuntu-14.04 & 16.04 as supported distributions this blocker<br>
> issue must be resolved at earliest. <br>
><br>
> Appreciate your Inputs !<br>
<br>
</div></div>What would really help is knowing what recipe is being built when this<br>
happens. There are a few ways you might be able to figure this out:<br>
<br>
a) Watching the screen to see which recipes were building when it<br>
happens<br>
b) Perhaps using some kind of screen recorder to automate this, you'd<br>
be able to review the recording to see when it breaks<br>
c) Looking at the bitbake/build logs to see what it was doing when the<br>
build broke (assuming bitbake stops when the session dies).<br>
<br>
"bitbake | cat" can provide better output for this since it will<br>
produce a scrolling log rather than the more interactive UI.<br>
<br>
Once you find the problematic recipe, a "bitbake XXX -c clean; bitbake<br>
XXX" should hopefully reproduce this more easily.<br>
<br>
Cheers,<br>
<br>
Richard<br>
</blockquote></div><br></div>