Bug 7338 - coreutils-native fails to complete in rm_work because of recursive directory structure
Summary: coreutils-native fails to complete in rm_work because of recursive directory ...
Status: VERIFIED WONTFIX
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.5
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.9
Assignee: Matt Broadstone
QA Contact: Bogdan Alexandru Voiculescu
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2015-02-19 18:33 UTC by Matt Broadstone
Modified: 2015-11-16 09:04 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Broadstone 2015-02-19 18:33:35 UTC
coreutils-native's configure script contains a check for whether getcwd handles long file names properly, which creates something like 850 recursive folders with the name "condir3". This compiles, and works as expected, however on the rm_work step in bitbake we receive the following failure:

NOTE: recipe coreutils-native-8.21-r0: task do_rm_work: Started
ERROR: Function failed: do_rm_work (log file is located at /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228)
ERROR: Logfile of failure stored in: /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228
Log data follows:
| DEBUG: Executing shell function do_rm_work
| rm: cannot remove 'coreutils-8.21/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3/confdir3': File name too long
| WARNING: /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/run.do_rm_work.14228:1 exit 1 from
|   rm -rf $dir
| ERROR: Function failed: do_rm_work (log file is located at /mnt/bitbake/build/detos/tmp-eglibc/work/x86_64-linux/coreutils-native/8.21-r0/temp/log.do_rm_work.14228)
NOTE: recipe coreutils-native-8.21-r0: task do_rm_work: Failed
ERROR: Task 8813 (virtual:native:/mnt/bitbake/build/detos/sources/openembedded-core/meta/recipes-core/coreutils/coreutils_8.21.bb, do_rm_work) failed with exit code '1'


A possible solution is to exclude coreutils-native from running rm_work, but that leaves cruft behind.
Comment 1 Matt Broadstone 2015-02-19 18:37:21 UTC
Other relevant information:

  * This is a build that is being run inside a ubuntu 14.04 docker container. The behavior does not affect a similar container running ubuntu 13.03 inside.
  * We are using dora
Comment 2 Saul Wold 2015-02-20 22:11:22 UTC
Just to confirm, you do not see this issue with Ubuntu 13.03 container?  Have 
you tried a newer release (16.2 or 1.7.1) or the git master.
Comment 3 Matt Broadstone 2015-02-23 18:47:41 UTC
This is a bit of a tricky situation, it seems totally unrelated to the base distro at this point (Ubuntu 14.04 vs 13.03), but rather because the CI bot running the job was running bitbake inside a docker container running inside another docker container. I'm not sure how likely it is that you will run into this with most users (probably not likely at all), but it does seem that rm_work is doing a "rm -rf $dir" and $dir is expanding to the entire path of that tree when it should just do e.g. "rm -rf confdir3" with no subfolders.

Having said that, we were able to overcome the issue by simply disabling the getcwd-path-max.m4 configure check in coreutils, for anyone else that happens to find themselves in this cave :)
Comment 4 Stephen K Jolley 2015-03-16 19:30:13 UTC
The information appears to have been supplied.   If this still is a needinfo status, please restate the question.
Comment 5 Chen Qi 2015-03-27 07:44:01 UTC
I cannot reproduce this problem.
Is there any way to reproduce it on a sanity tested host of Yocto?

Change the status to NEEDINFO util further information is provided.

Regards,
Chen Qi
Comment 6 Matt Broadstone 2015-04-20 21:13:24 UTC
I don't have time to continue to dig into this, changing to OBSOLETE for now
Comment 7 Douglas Royds 2015-05-25 21:24:03 UTC
The problem is that inside a Docker container, it is possible to create deeply nested directory structures that can't easily be deleted. I have opened an issue on the Docker project (https://github.com/docker/docker/issues/13451) including a few proposed work-arounds.

The coreutils configuration runs code from getcwd-path-max.m4 (from the gnulib project), which includes C code to probe the limits of PATH_MAX for getcwd(). It does this by generating a directory structure that runs out to PATH_MAX, and testing that getcwd() remains well-behaved. At the end, it politely attempts to remove this directory structure, but silently fails. This does not have any immediate impact on the configuration of coreutils, though a second attempt to ./configure does have a different result (as mkdir confdir3/ fails). It leaves the user unable to delete the coreutils directory after building, as observed by Matt.

We could potentially add the following work-around into the coreutils recipe, but I don't know that it's worth it:

do_configure_append() {
   # When running in a Docker container, getcwd-path-max.m4 leaves behind
   # a deeply-nested structure of confdir3/ directories that can't be deleted using rm -fr.
   # See https://github.com/docker/docker/issues/13451
   mv confdir3/confdir3/ fred || true
   rm -fr fred/ confdir3/
}
Comment 8 Bogdan Alexandru Voiculescu 2015-11-16 09:04:22 UTC
This will be fixed on docker side.