Bug 11681

commit that holds the fix: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=be8ceea70d3016027806d6c5adc8b567e8176aa6

I will be testing this commit to verify the bug, but this will be reported in 2.4M1 and it has to block testing. Because we have to run test on the commits released for 2.4 M1.

I'm not sure this fix is linked to this issue. The issue is likely caused by low memory on the machine in question or values of parallelisation which are too high. Either way, resource issues like this are likely not really bugs in the build system but lack of resources on the build machine. Can you detail the memory available, number of builds running and numbers of cpu cores on this system please?

(In reply to comment #1)
> commit that holds the fix: 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/
> ?id=be8ceea70d3016027806d6c5adc8b567e8176aa6
> 
> I will be testing this commit to verify the bug, but this will be reported
> in 2.4M1 and it has to block testing. Because we have to run test on the
> commits released for 2.4 M1.

Like I said via email, this commit fixes the gettext dependency, so its related to a part of the instructions to reproduce the bug (Step #3), this it not a fix, for the issue mentioned above, and I agree with Richard, its very unlikely that this is an actual bug, this is more related to the build machine that its being used, the information Richard just asked would help to figure out what the problem is.

(In reply to comment #2)
> I'm not sure this fix is linked to this issue. The issue is likely caused by
> low memory on the machine in question or values of parallelisation which are
> too high. Either way, resource issues like this are likely not really bugs
> in the build system but lack of resources on the build machine. Can you
> detail the memory available, number of builds running and numbers of cpu
> cores on this system please?

Only two members of GDC are asigned to the yctb05 server and I was the only one running builds at the time of this failure. I dont think resources of the server were the problem. I am not testing with the recent instructions given by hernandez.

liberta1@yctb05:~/poky_tiny/poky/build> free -h
             total       used       free     shared    buffers     cached
Mem:          125G       103G        21G       365M       179M        99G
-/+ buffers/cache:       4.7G       121G
Swap:         1.8G       5.3M       1.8G


liberta1@yctb05:~/poky_tiny/poky/build> df
Filesystem        1K-blocks        Used   Available Use% Mounted on
devtmpfs           65975532           8    65975524   1% /dev
tmpfs              65982704           0    65982704   0% /dev/shm
tmpfs              65982704      338684    65644020   1% /run
tmpfs              65982704           0    65982704   0% /sys/fs/cgroup
/dev/sda3          18574068    10260708     7346808  59% /
none               65982704       40668    65942036   1% /tmp
/dev/sda1            523248        4620      518628   1% /boot/efi
/dev/sda4       11696218112   600924600 11095293512   6% /home
tmpfs              13196544           0    13196544   0% /run/user/1089
tmpfs              13196544           0    13196544   0% /run/user/1098
yocto-nas://gdc 90716806144 10236900352 80479905792  12% /srv


liberta1@yctb05:~/poky_tiny/poky/build> lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Model name:            Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
Stepping:              4
CPU MHz:               2034.218
CPU max MHz:           3500.0000
CPU min MHz:           1200.0000
BogoMIPS:              5399.97
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt

(In reply to comment #3)
> (In reply to comment #1)
> > commit that holds the fix: 
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/
> > ?id=be8ceea70d3016027806d6c5adc8b567e8176aa6
> > 
> > I will be testing this commit to verify the bug, but this will be reported
> > in 2.4M1 and it has to block testing. Because we have to run test on the
> > commits released for 2.4 M1.
> 
> Like I said via email, this commit fixes the gettext dependency, so its
> related to a part of the instructions to reproduce the bug (Step #3), this
> it not a fix, for the issue mentioned above, and I agree with Richard, its
> very unlikely that this is an actual bug, this is more related to the build
> machine that its being used, the information Richard just asked would help
> to figure out what the problem is.

Thanks for the response, I have again tried to build poky-tiny with the same steps described above except step 3. It keeps failing I attached the file "logs_tasks_failed"

Created attachment 3832 [details]
logs_tasks_failed

(In reply to comment #6)
> Created attachment 3832 [details]
> logs_tasks_failed

According to the log, these are the errors I found:

Summary: 3 tasks failed:
  /home/liberta1/poky_tiny/poky/meta/recipes-support/libcap/libcap_2.25.bb:do_package_write_rpm

Caused by:
| libgomp: Thread creation failed: Resource temporarily unavailable


  /home/liberta1/poky_tiny/poky/meta/recipes-devtools/gcc/gcc-runtime_7.1.bb:do_package_write_rpm

Caused by:
| libgomp: Thread creation failed: Resource temporarily unavailable


  /home/liberta1/poky_tiny/poky/meta-intel/common/recipes-kernel/linux/linux-intel_4.9.bb:do_compile

Caused by:
| make[4]: fork: Resource temporarily unavailable
| /home/liberta1/poky_tiny/poky/build/tmp/work-shared/intel-corei7-64/kernel-source/scripts/Makefile.build:544: recipe for target 'net/8021q' failed
| make[3]: *** [net/8021q] Error 2

This is likely being caused becuase a certain user is only allowed to run a certain number of processes, and in this case the user exceeded the specified limit, hence why when fork tries to run it shows an error.

The amount of processes a user can run can be checked by:
$ ulimit -a

It might be worth it to monitor a runnning build to see if the limit is exceeded, once we can verify that, we can close this since if this is the case, then its not a bug.

This looks like a 48 core system and I suspect its running too many things in parallel and running out of resources. Please try something like BB_NUMBER_THREADS = "20" and PARALLEL_MAKE = "-j 20" and see if the issue still occurs. 

Monitoring the number of open files and active processes (etc.) during a running build would help narrow down which kinds of resource the system is running out of.

Poky tiny images were successfully created (core2-32 and corei7-64).

Poky tiny images were successfully created (core2-32 and corei7-64).(In reply to comment #9)
> Poky tiny images were successfully created (core2-32 and corei7-64).

tested in commit:98099349e358a9caaec8ec81f0d4abe588909cfe