Nicola Mfb wrote: > Upgrading frameworkd-config-shr-dev on root from > 0.9.5.9+gitr1536+017926ff44f61b981e0568223913e2db0e51f2d5-92+5e507b956c134ba8faf448ef814a0745512a808b-r7 > to > 0.9.5.9+gitr1537+29e5316c13768dff8a94b879e8f30c7baebef0cc-93+0c164b58a270c689e7381e1c63e0a94ba1947Downloading > http://build.shr-project.org/shr-unstable/ipk//armv4t/frameworkd-config-shr-dev_0.9.5.9+gitr1537+29e5316c13768dff8a94b879e8f30c7baebef0cc-93+0c164b58a270c689e7381e1c63e0a94ba1947af3-r7_armv4t.ipk > opkg: fork failed > opkg: fork failed > opkg: fork failed > opkg: fork failed > opkg: fork failed > opkg: fork failed > can't get //usr/lib/opkg/info/frameworkd-config-shr-dev.control open for read
This problem has been with opkg for a long time. In a nutshell, opkg builds *huge* in-memory databases. It also places many temporary files (some duplicates, in fact!) in the /tmp directory, which is a tmpfs filesystem, and thus also comes out of memory. In various parts of the code, it calls the fork() system call as well (in the example you post above, it forks a process to decompress the package and extract the control file portion of the package). The Linux fork() system call duplicates the memory space; both the parent and the child process have a copy of the parent's entire memory space. If there is not enough memory, the fork will fail outright, or the dreaded OOM Killer (Out-Of-Memory Killer) will terminate opkg. A set of patches exists that address some of these issues. They need to be ported to the latest opkg sources, however. In a nutshell, replacing the use of fork() and system() calls with vfork() will help a lot. I would also suggest that the patch to move temp files out of /tmp would also be a good idea. -Mike (mwester) _______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
