[agl-discussions] Raspi can't compile: Can't get CWD

Blayne.Dennis at elektrobit.com Blayne.Dennis at elektrobit.com
Tue Jan 24 16:03:09 UTC 2017


Is it possible for yocto to run multiple processes against the same recipe? In which case there might be a conflict from one process deletes files it no longer needs but the other requires, causing the race condition? 

-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly at intel.com] 
Sent: Tuesday, January 24, 2017 4:39 AM
To: Dennis Blayne <Blayne.Dennis at elektrobit.com>
Cc: dl9pf at gmx.de; automotive-discussions at lists.linuxfoundation.org
Subject: Re: [agl-discussions] Raspi can't compile: Can't get CWD

On Mon, 2017-01-23 at 21:39 +0000, Blayne.Dennis at elektrobit.com wrote:
> I just reran the commands in a new terminal:
> 
> devel at agl-worker-sdldev-VirtualBox-0-sdldev:~/workspace_agl/build$ 
> source meta-agl/scripts/aglsetup.sh -f -m raspberrypi3 agl-demo 
> agl-netboot agl-appfw-smack
> 
> devel at agl-worker-sdldev-VirtualBox-0-sdldev:~/workspace_agl/build$ 
> bitbake agl-demo-platform
> 
> 
> The same error occurs:
> | Can't get CWD: No such file or directory Couldn't stash directory 
> | before opening socket: Stale file handlepseudo: server connection persistently failed, aborting.
> | Aborted (core dumped)
> | WARNING: exit code 134 from a shell command.
> | ERROR: Function failed: do_install (log file is located at 
> | /home/devel/workspace_agl/build/tmp/work/cortexa7hf-neon-vfpv4-agl-l
> | inux-gnueabi/dbus/1.10.6-r0/temp/log.do_install.24665)
> ERROR: Task 3212 (/home/devel/workspace_agl/poky/meta/recipes-core/dbus/dbus_1.10.6.bb, do_install) failed with exit code '1'

To me, that looks like the current working directory of the process got deleted while the process is still using it, i.e. it's some kind of race condition. That this then leads to an error from pseudo would be just a follow-up error.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.





More information about the automotive-discussions mailing list